I’d like to be able to define a collection of repos/graphs/databases (whatever you want to call them, but including local directories) to act as one graph, either as a master graph including all linked repos, or just as a collection. e.g. I’d like to be able to add several local directories to a collection and have it act as one database. To act as one would mean 1) files can link to each other regardless of whether they are in the same local folder or online repo, 2) auto-complete suggestions are a combination of all of the databases, and 3) templates can be used from any of the databases. There are probably other functions that must be combined but you get the idea.
There might need to be something done to deal with conflicting custom css files. Not sure how to deal with that.
While I like the idea of Everything Buckets which house all my data in some respects I don’t like the idea that all my data (e.g. pages) is stored in a single repo.
Here’s the problem it can present:
When I’m doing my software work and tracking notes on it I don’t want to stumble over pages related to game projects, recipes, etc. There are certain silos of information that deserve some separation. Otherwise, when searching, querying, graphing, I might have my Thai Red Curry recipe pop up, or a video game idea. It’s a distraction. It’s a pull against focused thinking on my current set of related ideas. But there are times when pulling up dissimilar silos to define relationships makes sense. Thus one graph from many repos makes good sense to my way of thinking.
You would still have to choose an active writable repo to avoid having to be continually prompted about where to put new pages. Or maybe it just adds pages to the repo whose page is currently displayed.
The links shouldn’t be terrible, as they essentially become relative when crossing repository boundaries, e.g. [[../recipes/Thai Red Curry]].
There’s another way this could be implemented with a single repo. Tags could be used. If I tagged Thai Red Curry as “recipe” the tool could provide some convenient way of defining tag sets (groups of tags related to some domain, e.g. “food”). The menu could then provide a means of whitelisting or blacklisting these domains to keep them in or out of searches and graphs.
The first option I think is preferable due to its other benefits, but I mentioned the alternative in case the first is more difficult.
I am aware of Hierarchies, but I don’t think its current implementation addresses the concern about distractions.
The Logseq team is producing something excellent! Thank you.