Support subdirs for namespace hierarchy

@Gary_O. I’d like to look at it from another angle:

  • File system interaction is important for many reasons:
    • Keeping subprojects separate
    • Interaction with other programs
    • Version control
  • The file system’s single hierarchy is not powerful enough. Foldering is a dead end. It doesn’t work on the OS level for organization and it is not going to work for Logseq. If Logseq limits itself to folder-like namespaces, it will be eventually wiped out by a program that does not have this limitation.
  • The file system has all kinds of obscure constraints (path length, disallowed characters, max items per folder etc.), violating these might lead to data corruption and loss. First priority should always be the integrity of the data, but we don’t want to subject Logseq’s names to these constraints.
  • The devs already committed to not implementing hierarchies as folders, which is a sound decision in my opinion.
  • The file system is a useful additional degree of freedom, and it would be wasteful to use this to just mirror Logseq’s internal hierarchy.
    • file system location can be used to decide what files to sync, where to store files, what to delete, use multiple git repos etc.

I think there is a solution to all of these issues. The first items are obvious, but the last one is problematic:

  • Logseq should stop trying to own our data by restricting files to its own folder and disallowing relative paths.
  • Every OS folder should be a potential location for Logseq’s files.
    • If I start a new programming project in a separate folder, I should to be able to document the project in a subfolder of my program under version control, keeping attachments locally or wherever I want them.
  • In the absence of overriding properties in the .md files, Logseq should use the OS folder hierarchy (which it already does, but I am not sure this is officially supported).
  • If there are additional properties specifying parents (multiple), folders become one additional facet to access the data.
  • Every OS folder structure will be a Logseq hierarchy, but not every Logseq hierarchy will be a folder structure.
  • As the folder structure is less expressive and more restrictive than Logseq’s, folders can’t be the default
  • This is the problematic one: Could there be some option, plugin (?) to map individual hierarchies to the file system? This is not as easy as it sounds, because now all functions that create new pages need an option to create pages locally. If I am on a page “A” and create “A/B”, should B be in a subfolder of A automatically, or should it be in the main hierarchy? Should this be a per-file setting that makes all subitems into subfolders?

In the spirit of keeping things simple, I’d say the first step should be to make Logseq officially accept files anywhere on disk, even if it means manually creating them.

1 Like