I’m not sure if this is a bug, or a misconfiguration of LogSeq. LogSeq uses an encoded slash ’ %2F ’ in the file names of pages that contain names spaces.
This makes the filename challenging to read: root%2Fleave.md
Is it possible to use another character like a ‘-’ or ‘.’, to get a filename root-leave.md or root.leave.md ?
This probably will not be changed (any time soon). It used to be a dot, and that proved to be really annoying, so it was changed to the current character.
The current setup is robust, helps with namespaces, and is compatible with all OSes Logseq runs on. And in practice, how often does one really look at the files?
EDIT: actually, it would be way better if they just created FOLDERS instead. There’s a few other topics discussing this and that seems totally the way to go. Would much prefer this. Would make namespaces more useful.
True. While I understand the cross-platform reasoning for using the encoded flash character in the filename, the idea that ‘no one really looks at the file’ seem to conflict the whole idea of using markdown files in the first place. They should remain readable, otherwise I can just go for a closed format like Notion.
Therefore using folders makes a lot of sense to me, too.
@Alex_QWxleA - would there be any issue with that ?
I’ve asked one of our core engineers about this, and having namespaces create folders was considered in the past. The issue is that it completely kills performance, so it’s not a viable solution unfortunately.
The file is always readable, just file title just contains the character %2F whenever a slash is used in the page name. You still own all of your data in Markdown format, so the comparison to a locked platform like Notion isn’t fair IMHO. We’re still looking for potential alternatives, but this is the most robust solution as @Alex_QWxleA has pointed out.
well, if you’re calling me out on it… (and to be clear, these are my personal opinions, I don’t speak for Logseq):
No, still no reason to use folders (imho). My reasoning is:
Logseq is a collection of Markdown (or org-) files, using a small number of folders (pages, journals, assets and logseq). But the frontend hides all that. The frontend hides Markdown or Orgmode files. It hides journals or pages folders. All that is on purpose: Logseq is a Knowledge Graph, not a markdown editor.
Knowledge graphs have been invented to collect, reason and study information. The smallest piece of information in Logseq is a block. Blocks are collected in Pages. These blocks and collections of blocks (pages) can be used and reused in different contexts. Links, tags and references create relationships between nodes, and thus one piece of information can exist in multiple places at the same time.
This non-linear way of storing information is many times more flexible and powerful then the old hierarchical way of storing files in folders. Folders bind information to a single context, a graph is non-hierarchical by design.
To use Logseq effectively one has to completely change their way of thinking. Only then will people become real Logseq power-users: information is not stored in a place, it is stored in a relation to other blocks.
But can’t we do both? Can’t we do all that and have folders? Yes we could. The underlying system understands folders. (I even have one extra folder in my Logseq notes folder that is being populated by scripts from my system. Those scripts can be a little wonky at times, and I don’t want to mess up my pages or journal folders.) It is perfectly possible to create more folders and use them. You can do that today.
So it is technically possible. But “adding folders” means more than that. It means adding a file-manager. And then people want to be able to move files around. And copy files. And then Logseq becomes a slow version of Obsidian.
In Logseq the star of the show is the block. Blocks are queried. Blocks are moved about. Blocks are linked. And blocks are collected in pages. In legacy applications like Obsidian, the star of the show is the file. That doesn’t make it bad. It’s just not a block-based knowledge graph.
Asking for folders is like asking for a motorcycle with four wheels, four seats and a steering wheel. That’s not a motorcycle. That’s a car.
Feature Request: given the %2F seems a good solution, would it be possible to create an option to RENAME all files of so they use the same file name convention ?
My old ones use a ‘-’ and the new ones use ’ %2F '. And despite me following the logic here …
… I do think that a core feature of LogSeq over say Roam is local storage of markdown. For me the point there is partly owning my data and partly avoiding lock-in into one app. Hence, even if LogSeq hides the markdown files, keeping the local markdown organised consistently would seem to make sense to me for both human readability and for future use cases.
I also find it’s annoying that the file contains %2F. In fact, I like edit org file in emacs, and view it in logseq. I got some ideas from dendron that create file hierarchy with the name “xxx.xxx.org”. When I create file with such dots, logseq can parse it as hierarchy. This meets my need. But when I edit [[xxx/xxx]] in logseq, the filename will contain “%2F” instead of “.”. I hope there some workaround that I can have file name with dots when create hierarchy in logseq. Or it can offer some config choices for users to choose.
Hope for this feature request will be considered.
I agree with this point. It irks me to see some files named with a “%2F” used as a namespace for some files, and “.” (in my case).
It appears there’s a new filename format that substitutes “%2F” with a triple underscore “___” as namespace separator.
… write using an easy-to-read, easy-to-write plain text format … The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
Using %2F instead of something more visually understandable by humans goes against the spirit of markdown.
And in practice, how often does one really look at the files?
All the time; at the very least daily. I chose logseq rather than other tools precisely because it makes it easier to use with other tools that aren’t logseq. I can see the files on the system and use them that way. By using __ instead of %2F in hierarchies, I can main a visually understandable hierarchy that lets me import graphs into each other without loss. I often browse to a given markdown file in an external text editor with more robust regex-based find and replace functionality in order to do more sophisticated transformations. I also pull pages from my graphs into each other. I also commit certain pages to git and push them around.
I advocated for using LogSeq as part of our software documentation that gets checked into the repo because at the time it generated sane hierarchy-compatible filenames. These made it easy to see what you were editing during PR review. Now that’s all changed.
This would be easy if it was, say, double underscores everywhere. For example, say I want to import my notes from CS104 into my main graph. I just copy all the files that begin with CS104. Or if I just want to import the sections that have to do with algos, I can just copy the files that begin with CS104__algos. Only now I have to visually look at some irrelevant characters: CS104%2Falgos.
Or, as I’ve seen, I’m getting __ for hierarchy pages created on mac, and %2F for hierarchy pages created on Windows, so it’s inconsistent and, on windows, not visually intelligible by humans.
Update: On Windows I was using an older version without the update. Not sure why it didn’t auto-update; I had to manually download the update.
Please let us use some visually sane separator that’s consistent across operating systems.
There’s a reason the URL to this page looks like this:
https://discuss.logseq.com/t/is-it-possible-change-the-encoded-slah-2f-character-in-the-file-names-of-names-spaces/8037
and not like this:
https%3A%2F%2Fdiscuss.logseq.com%2Ft%2Fis-it-possible-change-the-encoded-slah-2f-character-in-the-file-names-of-names-spaces%2F8037
… it was meant to be understood by both humans and machines. The file systems in our knowledge base should be the same.