Support subdirs for namespace hierarchy

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

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.

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:


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?

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).

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

1 Like

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.

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

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

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.

@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:
folders:: [[Subfolder 2]], [[Subsubfolder 9]], ...

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

- {{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
  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.

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.

Yep, I described my setup here:

1 Like

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

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

Yeah, the term “Notebooks” seems appropriate, especially because we already have the “Page” term. Awesome idea.

Cool, I’m not really sure to know about that, would you mind writing a brief short summary, just a few sentences, on what is the problem and how this Logseq approach solves it?

Your list is on point, it seems that’s all we just need for the feature to be usable.

Remote solves this by not having any different between a Block, a Page, or a Notebook. They are interchangeable, they’re all just “Rems” in their terms. Rem with not parent is a Page, Rem with parent is a Block, Rem with no parent englobes Rem with no parent = Notebook (Folder).

The conclusion to all this seems to be: many users will greatly benefit from the introduction of a Folders-like management.

Last time a dev or team member spoke about this, they said something about “it breaks our design”. Maybe they did not explicitly said they won’t implement it, but they made it look like it.
I’m willing to change perspective on this, but they seemed quite stubborn on their claims.
Till that day, I’ll be stuck using an alternative app.

1 Like

It’s a matter of mindset, it seems there are people who prefer efficiency over order and viceversa.

I came up with this idea thanks to a meme in the community of mathematics. The summary is that someone noticed that almost all algebraists eat corn in a certain way and analysts in another way.

To me, it seems algebraists prefer order over efficiency and analysts prefer efficiency over order.

The same seems to be true respectively for Object Oriented Programming and Funcional Programming (incidentally Logseq is a written with a FP language, Clojure).

I think the dichotomy holds also for

  • Relational Databases: used by most applications to store the data. File systems can be considered as a subclass of RDB with more strict rules. We are familiar with RDB when we use applications like Excel, Access or Notion.
  • Graph Databases: it’s the data structure Logseq uses internally. We generally don’t interact directly with GDBs but they are very common today: they turn data into knowledge by adding context, they power Google search algorithms, recommandation algorithms on platforms like YouTube and are used in Machine Learning.

Many discovered Logseq as an alternative to Roam and maybe they already know what’s supposed to be the mindset. Instead I didn’t know Roam, I discovered Logseq as an alternative to Obsidian.

Being used with file systems (and RDBs in general) like most people I tried to use Logseq with this mindset.

Instead the “efficiency” pursued by Logseq (and Roam) consists in just writing content in blocks without caring to “place” it somewhere: just write (maybe in the journal), use [[wikilinks]] and #tags when it makes sense and let the structure (a graph) emerge naturally. Then use powerful queries to browse your knowledge base.

Properties:: and page-properties:: adds RDB capabilities to Logseq and so you can enrich your experience with queries. But the “native” approach by Logseq is the other one. I think in the future Logseq could add UI to improve the RDB experience, but if you want to use Logseq properly I suggest you to learn both the approaches and understand when one is more convenient than the other and how to combine them in the same knowledge base.


I see, thanks.

After having used this approach, maybe my vision could be limited or something, but I truly don’t see how having a Folder-like management in addition (this is the key concept I’m trying to convey) to the current “just write somewhere, add metadata, and then use Query” approach could damage the user.

The possibility of choice. This is the key for me. I’d like to have the right to choose which method suits my specific needs in specific situations.

A corny example: you can probably do the same operations on a smartphone and a tablet, but nonetheless one could certainly be willing to spend for both of them and choose which one to use based on the moment their needs occur.

The analogy with OOP and FP is great, although it may put it a certain way that could make you think “it’s either this or that”, which is most probably true for the programming languages paradigms, but here specifically talking about this feature in Logseq, I struggle to see their irreconcilability.

Meaning, if you add Folders-like management it seems unlikely it will be detrimental to the current set of features or workflows.

At least, that’s my opinion, based on the thinking that a software provides a set of features, and the users decides how and which one to use to better suit their needs.


OK, it seems like there are several schools of thought on this topic.

1: Logseq already has a hierarchy called namespaces, why not use the filesystem for it?
2: Logseq has namespaces, but the filesystem is inappropriate for storing it for some reason(s)
3: Logseq has namespaces and might someday have additional overlapping hierarchies, so it would be arbitrary to “elevate” just one (namespace) into the filesystem
4a: The underlying filesystem doesn’t matter, I don’t care about that, just want a better UI within logseq for manipulating namespaces
4b: the filesystem might be useful for some, but I mostly want a better UI within logseq for namespaces
5: What’s all this about hierarchies, who cares about those? There are many more interesting/advanced ways of categorizing notes; let’s have that discussion instead

At this point I don’t see much support for my original position (which is #1 in case you can’t tell). I thought it was simple and implementable without much work and would bring good value, but from this discussion what I hear is that most people are much more interested in much more advanced categorizations (even if they’re much more work).

BTW “Notebooks” isn’t really different from the existing namespace feature, right? You could just organize your notes as NotebookA/note1 and NotebookB/note1 and NotebookC/Section1/note1 etc. Of course there’s no batch select, move, or rename; see 4a and 4b above.


You’re right, maybe someone could think my posts and possibly some related ones are cluttering your FR somehow. The topic may be considered expanded as being talked about hierarchies.

We could at least agree that a form of hierarchy is of help for users. The actual implementation is being discussed then.

Thing to notice is that it seems no team member has given their thoughts in here.

Current hierarchy implementation (Namespaces) may be cool, but they also have their knowns limitations.

Great summary of the points made in the posts by the way.

(My very personal feeling, and I want to stress it’s just a feeling, that I’m sharing here, don’t want to make a point or anything, is that:
the team has made their decision about hierarchies; they believe Namespaces are sufficient, and they see the need of meticulously adding tags/metadata to your new info and creating simple/complex queries to retrieve them is the way to go.)

As I said I’m not against it and I don’t think it’s set on stone for Logseq devs neither. I think it just happened that Logseq focuses on the Efficiency mindset and the UI for a more RDB experience is just lacking at the moment. If one contributes to Logseq in that direction with a good implementation I don’t think the devs will refuse it. Indeed properties are a step in that direction.

I mean one should use the best approach according to the problem, not the situation. For example if I want to track books and their authors the RDB model is better for me.

Again it depends on the problem: sometimes OOP is very naturally the best paradigm and sometimes it makes sense to use FP instead. It’s not like a developer will always use one or the other, of course.

In my opinion, compared to other applications, Logseq gives very abstract, general and powerful tools and the user is free to build a custom workflow :slight_smile: . Indeed my “indexes” are a workaround that is possible thanks to the generic Logseq tools.

I don’t remember if I already mentioned it, but for example here there is my proposal to make it easier to add properties while keeping the efficiency approach: