Support subdirs for namespace hierarchy

Feedback Feature Requests
31

Last time I checked Dendron was all about the xxx.yyy.zzz naming convention, to the dismay of some users, in what sense did they “commit to the file system” since then?

32

They haven’t. I think the two issues are separate. If you had virtual hierarchies or treemaps, you could enjoy the same kind of hierarchy refactoring that Dendron enables. This hierarchy refactoring makes hierarchies less rigid and fragile. That is a desirable innovation for any system making use of hierarchy.

In terms of implementation, Dendron is using filenames. This is beset with problems, but undoubtedly there must be some tradeoffs.

“Commit to the file system” might be a useful feature for Dendron too, I don’t know.

I do know that hierarchy refactoring is a powerful feature for any knowledge management system though, and Dendron offers that feature.

1 Like
33

@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
34

At the moment we can create subfolders inside a graph folder but:

  1. A subfolder can’t contain a graph of its own, since /subfolder/logseq leads to conflicts with /logseq. This could be fixed by simply ignoring /logseq in subfolders.
  2. Files with the same name in different folders lead to the same conflicts. It’s really hard to decide how to handle this:
  • Should different files with the same name be different nodes or the same one in the graph?
  • Should different files with the same name be displayed both as the same page in Logseq or should they be different?
  • How to reference specific files in subfolders or parent folders instead of others with the same name?

Edit:

Another idea to make this simpler to handle is to use an extension like .lq for Logseq files and treat other .md files we have in our folders as assets. .lq files would have to respect the rule of “no files with the same name in different folders” while assets are referenced with relative paths. This doesn’t solve all issues though.

1 Like
35

Hey,

Regarding Folders and Virtual Hierarchies. Maybe the following information could be deemed as off-topic but it could help visualize the usage of “Hard Hierarchies”, i.e. actual folders in the file system Vs. “Virtual Hierarchies”, just virtual folders, a collection of pages.

There is a photo-manager app called Mylio that actually has this feature of Folders and Albums.
“Folders” are actual folders on the file system.
“Albums” are virtual collection of files (photos in this case) and other Sub-Albums.

Here’s a visual representation and explanation:

It seemed nice to relate Logseq possible folder and virtual folder management with Mylio Folders and Albums management.
At least, this gives a real and tangible representation of what the feature could be, and how it could help users to better manage their files/pages in Logseq.

Also because, it was written a lot on this topic, maybe someone who wants to grab the idea faster, can just see the blog post or some videos on how this other program portrays the feature.


At the end, I'm not sure I fully understand the motives of removing options for users. If many users would love a folder and/or virtual folder management *in addition* to the current link/backlink management, why just not give it to them?

What is the damage caused to users by adding this feature?
If there is no damage for user, then why not considering it? Just because “it breaks the current design”?
Is that a damage for users?

Struggling to understand.

If, on another side, the reason for not adding this feature is about development workload and prioritization, then, that’s a whole different matter. But users should be transparently notified on the underlying motives of the decision.

1 Like
36

@alex0 I haven’t fully thought this through, but another option could be to keep Logseq links “[[]]” as they are, referring to local storage with unique names, but make Logseq recursively follow file:// links to .md (or .lq) files and incorporate them into the graph.
The advantage would be that any files in any folders could be part of the graph, even for regular Markdown files that don’t follow Logseq’s extensions.
This way there would be two namespaces, one for [[]] and one using regular relative links.

I am not sure this is worth it.

There is another feature request in the pipeline on Cross graph referencing. Not clear how this will be implemented, but it might at least allow to have separate graphs for individual projects, as suggested by @memeplex.

1 Like
37

Yeah, this is exactly what I meant.

Another option is to use symlinks in Logseq folder that points to files in the rest of the file system. If I can make Logseq

  1. ignoring a folder for git versioning
  2. not complaining if I don’t sync it on other devices
  3. ignore conflicts if files have the same names in different folders
  4. ignoring .md files in a specific folder

I know that there is an option to ignore a folder, but it doesn’t work for me, I need to investigate.

Edit: no need to set anything, all the files in /assets are ignored, no matter if .md or something else. So one can just symlink anything on the disk to /assets.

But it seems Logseq doesn’t display links that it doesn’t handle (.png images, .pdf etc). I would like if files where open with system apps.

1 Like
38

Anyway, for what it’s worth, I just came across Remnote. Local-only graphs as Logseq, Easy to write Advanced Queries as well.

But, it also allows for Folders! They structure everything as a block, no difference between Pages or Block, Blocks can be just blocks, or pages, or Folders.
And, yes, Virtual Folders as well.

PDF note-taking feature like Logseq as well.

I think it has everything Logseq has at this moment. Tags, Block/Page Refs, Block/Page Embed, Journal, Flashcards, Multiple Graphs, Plugins…
But also some more features, advanced flashcards control, cloud-sync for online graphs…

It seems they had some bug issues with some recent update, yeah it could be concerning, but I don’t know, I have a feeling it will be settled.

Sorry to make this post about another tool, but I am searching for a tool that suits my needs, and I tried Logseq, I really like it, especially because it is very fast in everyday operations. But I realized, part of my graph really needs to be put inside organized hierarchies, aka folders. That’s it for me, can’t make it without them.

I believe there are other people who may be in my same situation, so I’m giving my opinions based on the time spent on looking for and testing tools that better fits my needs.

39

You can organize subfolders in your graph folder the way you like. You just need to be sure that files in different folders have not the same name:

graph/pages/subfolder/example.md
graph/example.md

The above would give an error because Logseq doesn’t know which one contains the block for the [[Example]] page.

We are talking about the file system in our hard drives here. Does RemNote solve the issues we are discussing here somehow?

40

Sorry, I think we are talking about different things.

As far as I know, those are file system folders. I need to work in Logseq with Folders. With Folders I mean just Folders containing Pages, and I need to work with them, to manage them, move them, whatever, within Logseq.

What difference does it make to open the Finder and create folders from the Finders and moving pages around when those changes are not applied/not visible/not workable with in Logseq?

I’m not exactly sure what your needs are, regarding one-to-one mapping of real folders inside the OS file system and Folders inside Logseq/Remnote, but for me, I just need to open and use the note-taking app and being able to create folders inside of it (mere collections of pages). I don’t need them to be real folders in the file system.

Answering your specific question, Remnote does have export in different options, Markdown included. But I think internally, the management is different because you don’t see plain .md files in the graph (Knwoledge Base in Remnote terms).

41

I’m working on a plug-in that should address your use case in particular @Prote

1 Like
42

Indeed, you are in the wrong thread, did you read the posts or only the title? :wink:

What you are looking for has been discussed here:

And here there is my proposal:

You would need the above plus a convenient UI to manage hierarchies like we do with folders in our drives.

43

@Prote would you be happy with a nicer UI (e.g. drag & drop like a file manager) on top of the existing “namespace” hierarchy, i.e. “folder1/folder2/page”? Or are you thinking something different than namespaces as implemented in logseq now?

44

That’s the kind of paradigm that makes sense to me and it’s what I"m personally working on

45

Yes, something different from the current Namespace feature.

It’s actually really simple, a place, a UI section, somewhere in the app, maybe accessible from the sidebar, just like Flashcards and the soon-to-come Whiteboards, you click on it and you open a new big window at the center in place of the page.

And there you have just plain simple Folders. You put pages into Folders. You can put a Folder inside another Folder. You can put a page inside multiple Folder, as you best believe to put them.
Column view, icon view, drag-n-drop, we know how folders work.

That’s it.


For my needs, I don’t need a one-to-one mapping between Logseq folders and File System Folders.

Now, if someone else may need that, you could think about 2 sections (the names I’m going to use are just examples):

  • Real Folders
  • Virtual Folders

That’s it.
Real Folders are actual folders in the File System.
Virtual Folders are not.
The other difference between them will be about “being able to put a page in multiple Virtual Folders”, whereas of course, with Real Folders you can only place a page in one folder.

Do you think that will help people better organize at least part or their graph? I believe so.

46

@Prote Did you try to just manually create indexes?

- [[Folder 1]]
  - [[Subfolder 1]]
    - [[Subsubfolder 1]]
    - [[Subsubfolder 2]]
    - [[Subsubfolder 3]]
  - [[Subfolder 2]]
    - [[Subsubfolder 4]]
    - [[Subsubfolder 5]]
    - [[Subsubfolder 6]]
- [[Folder 2]]
  - [[Subfolder 3]]
    - [[Subsubfolder 7]]
    - [[Subsubfolder 8]]
    - [[Subsubfolder 9]]
    ...

You can move (multiple) blocks with drag and drop or with keyboard shortcuts. You can have more than one index and they can share elements like your “virtual folders”.

If you want to move your “content pages” the same way you can put them as leaves of that hierarchy:

- [[Folder 1]]
  - [[Subfolder 1]]
    - [[Lorem Ipsum]]

otherwise you can use other methods to “put” your “content pages” in your “folder pages”, for example using page-properties:

Title.md
folders:: [[Subfolder 2]], [[Subsubfolder 9]], ...

And use a template so that in each “folder page” there is a query listing pages in that folder:

Subfolder 2.md
- {{query (page-property folders [[Subfolder 2]])}}

Remember that you can use <%current page%> in queries and templates to make things easier.

You can also have more properties and indexes and use them for blocks too, not only pages, for example:

- Logseq repo
  url:: https://github.com/logseq/logseq
  type:: [[link]], [[online resource]], [[git repo]]
  class:: [[software]], [[application]]
  tags:: [[PKM]], [[Note taking]]

The above type, class, tags are variations of the folders:: property above.

47

Hey @alex0 , thanks

Actually yes, I’ve tried to used “Folder Pages”, and to better recognize them and distinguish them from normal pages, I’ve also put a special prefix character in their title. Talked about it with @boisjere here just a few messages above Support subdirs for namespace hierarchy - #27 by Prote

I’ve really tried, for weeks, because I just need that part of my graph is to be put tidy inside hierarchies that could be opened/closed/traversed like normal file system folders.

Have you tried to operate with this workflow? I had, and unfortunately it creates sufficient friction and overload to your work that over the daily usage it makes it too heavy to manage.

It is somehow a partial solution, or more or less a stretched one. Not first class management.

48

Yep, I described my setup here:

1 Like
49

Great, some observations could be made.

It seems we have similar needs at the end of the day: Categorizing (even just part of) our graph.

The slight difference seems to be on the method used: you create Index Pages, whereas I would also be in favor to have the possibility to choose between Index Pages and Folders (real or virtual for what it matters). But I can’t seem to find any argument from your side against this possibility of favoring one of the other method based on specific case-by-case needs.

Second thing to notice, which is strictly related to the screenshot in the post you linked: the screenshot portrays a structure of topics which is commonly found around. I mean, the specific structure you’re working with is somehow already defined in most of its part:

  • Maths
    • Real Analysis
    • Complex Analysis
    • …
  • Algebra
    • Linear Algebra
    • Boolean Algebra

and so on…

This kind of structure can be very different from a structure that must be molded over time, a structure that emerges with constant usage, with thinking, with collecting new info, with connecting them, etc…

In this situation, the amount of transformations that the Index Pages will incur is substantially different from a pre-defined and relatively well established structure, like for instance studying academic/scholar topics, in which categories and subcategories are less prone to changes.

In scenarios in which the structure is susceptible to a reasonable amount of variations, revisions, amends, improvements, adaptations, etc… the Index Pages may be less flexible than the Folders method.

I say it may be because, as of now, Logseq does not have the possibility to use the Folder method, so we don’t have actual comparable data on it. My feeling, though, is that it could be of help in more than a few cases.

1 Like
50

Indeed I’m not against it, it’s just that Logseq has a different approach (I call it Efficiency over Order, I plan to write more about it in this forum).

I think what we need is an UI that makes my workaround feel “native”:

  • call them Virtual Folders or, even better Notebooks, to differenciate from our file system folders
  • reserve a special page-property to specify in which Notebooks a Page is
  • create a file manager-like UI that, when you move a Page between Notebooks, updates the page-property accordingly

The only thing I have to better think is: I would like Notebooks to be referenced like [[Pages]] but then every Notebook need an unique name, instead we may want to differenciate them according to the path:

[[Notebook A]] / [[Subnotebook]]
[[Notebook B]] / [[Subnotebook]] (different from the one above)
1 Like