Proposal: Changing How Namespaces Function in Logseq

Bader · December 1, 2021, 3:06pm

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

InfiniteRecursion · December 2, 2021, 6:24pm

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.

olivier · December 4, 2021, 9:15am

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

dcoales · December 18, 2021, 10:20pm

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.

Ramses · December 20, 2021, 1:10pm

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.

rynco · December 25, 2021, 7:26am

Bader:

graph/pages/root
├── branch1
│  ├── branch1.md
│  └── leaf1
│     └── leaf1.md
├── branch2
│  ├── branch2.md
│  └── leaf1
│     └── leaf1.md
└── root.md

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.

Gary_O · January 6, 2022, 9:48pm

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.

brandontoner · January 10, 2022, 2:04pm

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.

brandontoner · January 10, 2022, 2:07pm

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)

brandontoner · January 11, 2022, 8:00pm

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

fredguth · January 23, 2022, 12:04am

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.

Coffeeling · February 17, 2022, 2:27pm

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

Coffeeling · February 17, 2022, 2:32pm

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.

Vincer · February 20, 2022, 1:38pm

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

Vincer · February 20, 2022, 1:45pm

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

mat_rhein · May 4, 2022, 9:00am

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

alex0 · May 6, 2022, 2:59pm

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]]

stef · July 6, 2022, 4:22pm

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.

gax · July 6, 2022, 7:24pm

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.

mat_rhein · July 20, 2022, 11:01am

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

Proposal: Changing How Namespaces Function in Logseq

Current Implementation

Current Implementation Limitations

Proposed Solution

Proposed Solution Implementation Limitations

Conclusion

Problem and solution