Then you should try Trilium Notes … Does exactly that.
Hey, thanks for the suggestion. I actually found my peace with Remnote now. It has everything Logseq has, plus a bit more features, (IMO) a nicer UI/UX, and of course Folders.
For visual Whiteboards, I’m using Heptabase for now, really intuitive. Will check out WBs in Logseq when they will be released. Remnote also plans to add them in the future; they are now focused on tables.
Logseq is great, don’t get me wrong, but after using it for some weeks, I felt it’s still a bit rough and perhaps it leans on satisfying a workflow and mindset of structuring the whole experience for more developer-like users, not sure how to express it better (just my impress though).
2 Likes
Has anyone imagined the idea that a virtual directory, notebook or collection of pages, as a one more block in the graph, but actually being a link to a new graph? (that could receive certain parameters and inherit certain properties, for example, that we could call context).
Perhaps it is something drastic, but it illustrates the concept of namespace as a synonym of another (sub?) graph space, and the layout of it as an output of some kind of function or query. Doesn’t it?
Related thread about namespaces. It’s a use case of using diferents graphs as namespaces:
So the idea I described in my previous message it’s that but visualizing them as a branch of a root graph (and with the optional feature to visualize that “sub” graph according a filter, etc), in a kind of a browseable graph.
Did you already see this proposal? Specify and display relations between pages/tags
The idea is that a multi-level folder structure is a tree extracted from a graph; instead of having a predefined folder structure, the user could use any property:: as an indication on how traversing the graph and so be able to browse that tree.
We could even concatenate more properties:: as indications, for example genre::, year:: and artist:: to browse music albums starting from genre folders, then years and then by artist.
1 Like
I’m glad this discussion is ongoing. Thank you all, especially @Gary_O whose summary taught me a few things I had not considered.
TL;DR (i have some detailed writing about this but I’m sparing you) I usually don’t propose solutions because if the problem is well-defined enough, there are smarter people in this room who can come up with the best solutions. So I apologise in advance.
So, what about the ~, ~/., ~/ws/git, ~ali/ws/sandbox/model/MasterData, notation? We can map tilt, ~ to base directory in Logseq and the command line context starts from there. But if I decide to create a file in Logseq (logseq’s strength) and whatever I type in that file in Logseq is created or updated exactly in the right place/path on the filesystem. Effectively, Logseq becomes the context layer of, my workspace where my filesystem manipulations are relevant to Logseq as opposed to the entire thing.
In fact, already now, I wonder why this doesn’t work:
Cmd + K, then I type ~/ws/scripts/replace-all
If this file actually opened the actual file sitting on the file system, I would be golden. Because in my case, it’s the file itself that I look to document so I don’t see why I have to maintain a separate entity if the page is directly mapped to the file on the file system. And the trick is the follow the directories, which is not happening now.
Another Example is how I produce master and reference data for my app.
Also, please also consider the mapping to URLs, as well, which I have posted about but closed in favour of this thread for simplicity, but let’s please also discuss how we map to URLs.
Also, @Didac started another thread along the same lines: https://discuss.logseq.com/t/integrate-logseq-with-the-command-line/12018/2
Checkout this workflow:
Over email, I had to exchange a number of important financial documents regarding a real-world topic, which has aspects that go beyond digital life, but also I tend to excerpt an unreasonable amount of control over these types of document exchange. For instance, one of the imperatives for me is that files must be grouped in one place. Cause at the end of the day, you know that tools come and go. Although I think Logseq and I are married for life, but still it’s that conservative way of thinking in specific situations that ask you to not overthink it. Make a folder, put them there.
And this is the twist of this workflow. HEY.com people have understood this nuance very well. As an email client, IMHO they represent the state of the art in their category.
- Now, imagine I already have a folder in Dropbox or a backed up file system node [^1].
- The name of this folder usually corresponds to a well-known topic that is well-documented.
- The odds are good that the topic in Logseq was even created before the file exchange.
- Or not. Either way,
- Cmd+K and BAM, I’m on the topic. I just drop the files and start typing.
- I as the artist of my knowledge graph will make sure that when I find my topic, that I land under:
~ws/2022/Budget Forecast 2023
and this is mapped to
/Users/skh/ws/2022/Budget Forecast 2023on the filesystem
Here’s the twist, this can only happen if Logseq follows subdirs. Because I need to be connected to the filesystem context so the files land, exactly where I want them to, rather than all in assets.
And in fact, it’s the disconnect between the filesystem context of the assets and that of the topic page, that is the key to understanding my argument here. For real world topics, some want control, some want files grouped in classical directories. In fact, Logseq does present filesystem parity as one of its main features and rightly so. You guys are gods in what you do. But this breaks that imperative.
[^1]: Backed up of course because these are things I intend to keep for 7 years (at least) (required by Belgian law)
cc @Didac
@sindoc The dev’s already said they will not map namespaces to folders, and they have good reasons for this decision.
On the other hand, arbitrary relations between pages can also be specified as attributes.
This technique can easily reproduce the folder structure that you desire. Currently there is no way to display the results, but it seems to be on the queue.
Independently of this, I would love to see the ability to have local Logseq graphs spread over multiple folders. It is a bad design decision IMO to force all Logseq files into one folder and force the user to copy all files into assets (relative links out of assets don’t work). You do not want to re-built your entire filesystem hierarchy in the Logseq folder.
A more natural solution is to go to your budget folder, put all the relevant Logseq files into that folder, and link to them as needed from the outside.
An additional advantage is that you keep all your financial files in one spot, so you can backup and don’t intermix them with your main graph.
It also reduces the risk of accidentally leaking finance info sitting in the same folder with cooking recipes.
Could you please point me to the reasons why it would be an issue to map to FS directories? And have you given thought to the tilt notation? It’s a Unix-compatible notation that also provides focus and natural filtering so the whole file system is NOT in logseq. That’s indeed not what anyone wants. But if I know that ~/ or ~ws/ is bound to a Logseq context, then I can use symbolic links to make sure everything is in the right place.
Indeed and I agree, we don’t want to re-build our entire filesystem in Logseq. But under a base, why not? In order to support the use cases I have defined.
Oh, and Logseq doesn’t scan. It acknowledges the existence of a file only when the file is created through it. So if I do mkdir -p foo/bar and then touch hello then hello is not supposed to show up in Logseq
But if I Cmd+K in Logseq, and say ~ws/foo/bar/hello, then Logseq places the file under the /Users/skh/ws/foo/bar directory, if it finds it, otherwise Logseq does create it.
This article might be worth reading for many contributing to this thread: All you need is links - by Gordon Brander - Subconscious
2 Likes
That was quite the read, interesting because the whole concept of folders is something we can only discuss because Logseq is a local tool. With most web applications there is no such thing as folders because it’s all in one big database that we can’t access.
While it’s my personal belief that the folder structure should always be separate from the data because it would add a limit and complexity that isn’t needed, we should be able to organize our files. This isn’t easy though…
Take into account that Linux, Windows, Mac, iOS and Android all have slightly different implementations of the file system. Think owner, file rights, special characters, capital letters. Special folders
And when moving/renaming a file, you don’t want links to break. All things that are way easier in DB’s because every file get’s a unique ID, but I don’t think anybody here would be happy with a pages/1.md till pages/9999999.md 
That said, I do think that being able to organize your files like you want because there’s plenty of good reasons to group files. For example, I made a DND template and moved everything in DND/ so people can git clone and later update the pages/DND folder.
On the other hand, sync caused me to deal with way to many duplicate files and this is marking an issue that any Markdown backend has, who’s leading? The .md files or the local database? How to avoid conflicts and file loss.
(Happening all the time to me, too many devices, constant moving of files)
Did a bit of digging through the github issues, but it’s hard to find a clear ticket for this and the decision behind this. This doesn’t help to get information on a clear decision that was made. Something that would help to determine what is new feedback that might effect the decision and what is just decided for now.
3 Likes
For Logseq, I understand the files and the file system as an interface to Logseq.
One more user interface in which to print information and from which to obtain input.
While it is the case that the database is built from scratch from the files each time we run an instance of Logseq, the files are not the graph.
In this sense, there is already an intermediate layer, and there may be specific interfaces for each file system.
Regarding file modifications made outside of the application, or by another instance, and the conflicts that may arise, it occurred to me that it might be useful to also save a dump of the database in a single file that, for example, could later be used to make a diff with which to present different solutions to the user.
For example, if X file is no longer found and there is a new one with the same content, it is easy to deduce that the name has simply been changed and, why not, update the existing links in the rest of the files that pointed to the old name.
Because a change made to the files, as an interface, is not conceptually different from making a change from the Logseq graphical interface.
1 Like
Was reading this feature request, largely having the system folder level structure somehow incorporated within organization in logseq seems like an important feature for me.
I have recently migrated to logseq, and one thing which is absolutely clear is that while Logseq is great at all the notes I take going forward, all my notes in my previous markdown only note taking and journaling cannot be easily migrated, since I have several files with the same name (e.g. README.md, LandingPage, Index etc. in different topics).
For all notes going forward, logseq does allow you to mantain folder structure, but I have to manually go through the process of organization and move each doc to the folder I want so as to not lose all notion of file structure on disk.
Importing large amount of notes on the other hand is an annoying tedious task.
That said search and block level indexing is super useful.
2 Likes
You could rename your files using either a dedicated renamer tool or a shell script so that they get namespaced in Logseq. Read the docs for namespaces if you haven’t already found out about them.
Well said. This is aligned with the use case I have described earlier.
Logseq seems to be in a unique position here. On the one hand, it is connected to the local file system and helps organise pretty much anything going on in our digital lives, and on the other hand, Logseq can be connected to the rest of the Web via APIs, plugins, and separating the private from public.
Nowadays, I’m trying to integrate Warp (command line , more and more with Logseq as Warp treats Unix commands as blocks, which maps nicely to Logseq blocks.
I agree that supporting directories adds complexity to Logseq but these are complexities that have already been solved. It’s a bit comparable to virtual machines in the world of programming languages. JVM was adopted and continues to shine because for the first time, we had a large-scale virtual machine that enabled developers to write code in Java, Groovy, Clojure, etc. and then run that code across any OS. Logseq should be able to provide a layer of abstraction that also hides the OS-specific complexities.
2 Likes
Solved yes, but still not free to implement, debug, maintain. And in a way Logseq already hides the OS-specific complexities by not showing a folder structure. This part I also like, because with alias I can add the same document in multiple structures. For example I have Energy in Topic/Health/Energy and Topic/Productivity/Energy.
2 Likes
I totally agree. It’s a question of perspectives. One perspective is to go from something logical and potentially find file system contexts related to that high level topic.
Another perspective is to start from the file system context and end up linked to the logical structure you maintain in Logseq.
I’m thinking of something like Warp command line, which already does treat commands as blocks. One would think that it would marry nicely with Logseq. But the link from file system to Logseq context is lost at the moment.
And if you look at my proposal, we can have a separate namespace in Logseq for anything file system e.g. a filesystem path that starts with ~/
One use case I have for this is to have Logseq be my personal middleware. I have file system contexts that contain executable scripts or a set of commands, simply that need to be run in a specific directory on the filesystem (filesystem context). I could have Logseq be an executable README (an experience maybe similar to Jupyter Notebook) for certain directories that are linked to the topics I manage in Logseq.
This is exactly me need. I mean I want to be able to have several folders that I can merge and then open in Logseq (for maintenance, archiving or better history/version management, but also for privacy reason). I organise all my files and assets in in structure like yyyy/mm/dd (time path). Each time I modify a file, it is copied in the current time path. As it’s not possible in Logseq right now (basically, for md files, two files of the same name cannot coexists whereas the “last” version could be used), I need to read and parse everything to change file paths… I also cannot change file name of course (one solution would be to use properties for that purpose). Not that easy ! Moreover, I’d like to be able to record also ressources that are read (not only written)… If people understand me and are interested in such usage, we could join forces (ie. have to preprocess/merge directories before opening Logseq) .
1 Like