Proposal: Changing How Namespaces Function in Logseq

  • Current Implementation

    • Currently, when creating a file in a namespace, for example, [[root/branch/leaf]]
      • Logseq will save the file on disk in the format root.branch.leaf.md
        • Logseq converts / to . due to / being a reserved character in many filesystems, and it’s used to indicate a file path example: /home/user/Documents/file.md
        • Logseq will also add a property to the page to display the title differently from the filename on disk
          • title:: root/branch/leaf
            
  • Current Implementation Limitations

    • Higher possibility of reaching the filename maximum character limit for most filesystems (255)
      • Including the default filesystems for Windows, macOS, and Linux
      • Note that the page name is still enough for most use cases.
        • the max limit would look like this
          namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.namespace.na.md
          
        • This is not likely to cause an issue for many users until it’s too late. Some users have reached this limit with just the note tilte: Write to file failed.. Error: ENAMETOOLONG: name too long Β· Issue #3327 Β· logseq/logseq Β· GitHub
  • Proposed Solution

    • Add hierarchy properties in logseq
      • Example:
        • Creating two pages [[root/branch1/leaf1]] and [[root/branch1/leaf2]] will result in automatically adding the following properties
          • properties of the page leaf1
            • title:: root/branch1/leaf1
              parent:: branch1
              sibling::leaf2
              child::
              
          • properties of the page branch1
            • title:: root/branch1
              parent:: root
              sibling::
              child:: leaf1, leaf2
              
          • properties of the page root
            • title:: root
              parent::
              sibling::
              child:: branch1
              
          • Note that the empty properties do not need to be added if not used. I just added them here to make the example easier to understand
          • Note that the property title:: functionality should remain the same
  • Proposed Solution Implementation Limitations

    • Conflict with duplicate children

      • example:
        • Creating the pages [[root/branch1/leaf1]] and [[root/branch2/leaf1]]
          • Notice that the page in root/branch1 and root/branch2 is titled leaf1
            • if both files were to be saved on disk as pages/leaf1.md, then the files will be overwriting each other
    • Solution:

      • Create sub folders for namespaces
        • example:
          • Continuing from the last example. When a user creates the pages [[root/branch1/leaf1]] and [[root/branch2/leaf1]], the structure on the disk will be the following:
            • graph/pages/root
              β”œβ”€β”€ branch1
              β”‚  β”œβ”€β”€ branch1.md
              β”‚  └── leaf1
              β”‚     └── leaf1.md
              β”œβ”€β”€ branch2
              β”‚  β”œβ”€β”€ branch2.md
              β”‚  └── leaf1
              β”‚     └── leaf1.md
              └── root.md
              
        • Solution Limitation
          • Creating multiple nested folders that only contain one page is not optimal
  • Conclusion

    • The current implementation does not seem optimal and could be improved
      • Adding properties to manage hierarchy and storing namespaces as folders solves existing limitations, and in my opinion, seems like a better way to implement namespaces.
    • Please let me know if there is some limitation that I missed or if you have any feedback on the proposal

I think using folders for namespaces works, even if it means some folders have 0 or only a few files, but contain folders that have more files in them.

It might seem weird but it’s still an organic way to browse files/folders and should make organizing namespaces easier.

7 Likes

Interestingly, your proposed solution is similar to current method used by Breadcrumbs plugin to enable custom hierarchy for notes in Obsidian

And the current implementation of Logseq is also the philosophy of Dendron

It’s amazing to see that there is a point of convergence for great ideas

4 Likes

Having a folder structure as well as parent links would be very useful. I’d rather the children property was optional though. I might have many children in a folder and wouldn’t necessarily want them all listed as a property. Presumably you could find them in the backlinks though. In an ideal world I’d like a file manager tool built in which would let me move a file and have all the corresponding properties, links etc automatically updated.

1 Like

Thank you for this suggestion @Bad3r, 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.

7 Likes

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.

1 Like

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.

1 Like

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.

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)

1 Like

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.

2 Likes