Proposal: Changing How Namespaces Function in Logseq

What about only creating folders for namespaces in the middle, like this:

graph/pages/
|- root.md
\- root/
   |- branch1.md
   |- branch1/
   |  \- leaf1.md
   |- branch2.md
   \- branch2/
      \- leaf2.md

It should be cleaner than the original structure.

Problem and solution

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.

3 Likes

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.

3 Likes

Another idea on this:

While on a page, say “Areas/Personal”, it would be cool to be able to directly add a child page in the hierarchy from that page.

See image for rough mock-up.

5 Likes

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)

11 Likes

Found the post for that request: Collapse namespace prefixes - #10 by brandontoner

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.

16 Likes

The filename limit can be disabled, as far as I know.

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.

1 Like

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

2 Likes

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
4 Likes

In the end, this structure could even be used for navigation as an alternative to the graph.

2 Likes

Maybe don’t make a particular naming scheme mandatory but just use folder structure to organize namespaces:

Food (folder)
    Pizza.md
    Fruit (subfolder)
        Apple.md
        Banana.md

Same folder reference:

We are in Banana.md,
let's reference Apple:
[[Apple]]

Child folder reference:

We are in Pizza.md,
let's reference Apple:
[[Fruit/Apple]]

Parent folder reference:

We are in Apple.md,
let's reference Pizza.md:
[[../Pizza]]

A subfolder hierarchy would be extremely appreciated rater than the parent%20child%20subchild.md file naming we currently have.

I don’t see a point of having a single folder with everything in it.

3 Likes

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.

6 Likes

In addition to all these good suggestions, Aryan’s overview on the usage of namespaces was hugely helpful to me.

Folder structure is needed to create a content manager in Logseq

The folder.md should list also inside files (at least first child)

I discovered that I can move .md files in subfolders in /pages or other subfolders of the graph. Logseq use them like they are in the same folder.

So the folder structure in the file system adds another hierarchy that is independent from the others and Logseq is not aware of it.

For me this is another degree of freedom, I like it.

But I would like if Logseq let me choose in which folder a new page is created when I click “New Page”.

And I would also like a full-featured file manager instead of “All Pages” section, where I could move, rename etc the files.

3 Likes

See also Support subdirs for namespace hierarchy - I tried to simplify and clarify this feature request down to just “support subdirs as namespaces”.

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_O title:: property is providing a “manual” way to manipulate the namespace structure

4 Likes

Our vision is to separate namespace structure from the limited tree structure of file system.

I’m utterly glad to hear that! :heart: