Thank you for this suggestion @Bader, and for those upvoting this.
Better namespacing is definitely on our radar, also because several members on the team use it (myself included). However, to best implement this feature and ensure backwards compatibility, we need to more time to scope the solution and its implications. It’s definitely on our radar, but we need more time to also put it on our roadmap.
I’ll put an update in this topic once I know more about how and when we’re going to tackle this.
Problem: If someone used .md in the middle of the path, like foo.md/bar, we would be creating a folder called foo.md (the file will be foo.md/bar.md), which has the same name as a page named simply foo.
Solution: We can add .d in the name of every folder to indicate it’s a directory instead of a file, so the file path becomes foo.md.d/bar.md and does not interfere with other paths.
I think this is an important feature. I have about 1000 pages (more or less) in my OneNote. I’m exporting them now as a tree of .md files using alxnbl’s OneNote MD Exporter, and it would be great to just copy them straight into Logseq without having to run a fancy script over them to create “namespaced” filenames and add the title metadata.
As well, I’d love to be able to toggle how namespaces display — in Roam, you can toggle between:
Full display: [[Areas/Learning Logseq]]
Abbreviated breadcrumbs: [[A/Learning Logseq]]
Hide Parents: [[Learning Logseq]] (the color changes on this mode to indicate that there is hidden information, to differentiate between normal pages)
My main usecase for having subdirectories as namespaces is the possibility of having different repos for each of them which I can share with different people. Me and my wife can share a repo “home”. My brother can be in a repo “family” with me and my wife. And I can have a repo for work related things which I would share with coworkers.
Using folders for namespaces has advantages, but also disadvantages: One of the big benefits of namespaces in the filename is that you don’t have to click through a bunch of folders to find files. Of course, this wouldn’t be an issue inside Logseq, but could be a problem for other files.
Internal links, too: the file [[foo.bar.banger]] having a link to [[music.ohno.rickroll]] is easy to parse more or less regardless of the app used. Folders would necessitate hard file path based links.
Just adding that besides overcoming the limit and making it easier to share only parts of a graph, it could open up logseq to automatically regonize new files inside folders properly in the hierarchy
That would enhance the crosscompatibility and usecases of using logseq alongside other apps, from markdown based to pretty much anything really.
For example i could right now hardlink some md file from elsewhere into a logseq subfolder and - if/when hierarquies work through folders- it would already be ‘where it should’ inside logseq
I think that, if we had to choose only 1 way folders would outweight namespaces
BUT i think logseq could implement both and give us the option
Proposed way for having both methods:
When users make titles using DOT, namespaces(filename) only
when typing / logseq would insert the file in a matching folder or create a new one
Then logseq could also match namespaced pages/hierarchy to folders, and treat both ways equally inside logseq itself (ie both files folderA.file1.md and file2.md inside a folder called ‘folderA’ would appear as children of a single folderA inside Logseq)
Plus logseq could create and delete folders on the fly not creating a file for their page until something is written on it
Some other cases to keep in mind:
when a new page is created as page/new-page when ‘page’ already exists, logseq would need to create a folder for that page and move it inside of it
I would also like to see subfolders, for the following technical reasons:
to avoid long pathnames as brought up by the OP. There are ways to enable long pathnames on different OSs, but some programs do not support them and might fail in unexpected ways later on, files might get moved to an even deeper hierarchy etc.
to avoid too many files in one folder.
NTFS limit very high, but substantial slowdowns happen even with a few thousand files
FAT32 (USB drives) has a limit of 65k files. A number that can be reached easily
to share different subfolders, as suggested by @fredguth and @Vincer
to interface with other software through automatic generation of .md files in a watched folder
On the other hand, I don’t think subfolders hierarchies are a good way to make information accessible, because one easily runs into many problems, as discussed in an article.
I just wrote a feature request for hierarchical tags, which have many advantages over subfolders, including the ability for one item to be part of multiple hierarchies and no limit on the path length or nesting limit.
From that point of view, I think the subfolder system should be optimized so that the storage issues (no long pathnames and not too many files in one folder) are addressed first, and it should be kept simple enough to make interfacing with external programs easy. If folders serve as an extra tool for organization - that is great, but I wouldn’t sacrifice speed and stability.
Calibre let’s one pick different export formats to convert the internal folder structure, such as {author_sort}/{title}/{title} - {authors}. Logseq could also maintain a set of hardlinks to present a different view for external programs.
Yes. Our vision is to separate namespace structure from the limited tree structure of file system.
Namespace is for concept disambiguation. Creating sub-dir by default would imply that every page should have a namespace (sub-dir), which violates our design.
Besides, the namespace file naming is going to be changed in Feat: new file name escaping rules by cnrpman · Pull Request #6134 · logseq/logseq · GitHub
@Gary_Otitle:: property is providing a “manual” way to manipulate the namespace structure