This functionality is super achievable in Emacs. With org-babel + org-roam, one can do literate programming inside a fully-indexed knowledge management system, with all of the advantages of an IDE to boot. There’s even a very cool paper about this concept in the context of education and research. It doesn’t touch on a full PKM but otherwise goes pretty in-depth about why this is desirable and achievable.
Now, this is certainly not “a first choice for non-programmers” and Logseq is much friendlier to the average end user, but with something like Doom Emacs it does not take a significant amount of effort to get going.
Dendron is definitely a good source to pull from for ideas, but my impression was that it made it far too easy to impose far too much hierarchy. Personally, when I use a system like Logseq, I want storage and retrieval to be largely the same action, friction-less and organic
I used org-roam for a while before logseq. I don’t manage very much code in my day-to-day, but on the occasions that I did, this functionality was extremely useful, especially since my coding knowledge and skills are limited. I did not have to be confused when coming back to things I hadn’t touched in a while, since I had prose-level editing for my personal documentation.
@mentaloid there is a wide range of possible integration with the file system:
being able to manage files and folders from Logseq UI similarly to what Obsidian does, including updating ![]() links when moving assets;
reuse the outliner UI to implement (1) i.e.:
the file management could be treared like a special page that can be opened in the sidebar too like the others;
files and folders would be blocks with limited editing capabilities i.e. the content can be only a text string used as the file name and eventual #tags would be added to files when the file system supports it (for example via xattr);
file-blocks have properties based on files metadata, some fixed (for example duration of a video or size of an image) and some editable where it makes sense, modifying file metadata like xattr;
file/folder-blocks should have the same capabilities of normal blocks when applicable including focusing the view on a block, open it in the sidebar, referencing or embedding it and being findable with queries; there should also be special queries operators like (ext pdf), (size 1920 1080) etc;
the content of some file formats could be used to generate further hierarchy i.e. children blocks for file-blocks, for example:
chapters and bookmarks in PDFs, ePub, HTML and other document formats
chapters in video and audio files
elements in a audio/video playlist like m3u
given content like query results, a page containing block/page embeds or a block and its children, expose it to other applications/tools by mounting virtual read-only Markdown files using FUSE or a local WebDAV server (useful for example to automate publishing using Markdown-based site generators);
given some kind of hierarchical structure (like indented blocks or relations defined by properties) expose it as folders like in (3); for example query results grouped by a given properties could be mounted as Markdown files grouped accordingly in folders;
if possible integrate with other file managers, for example drag and dropping files and folders between a file manager and file/folder-blocks actually moves files and folders.
I guess I’m really describing a cluster of attributes:
I want storage to be frictionless - If I have something to write down, I don’t want to need to think about where that happens. In my own use of Logseq and org-roam, this is the daily journal page. If I have information to store, I can drop those in that day’s page, and if it’s worth surfacing in the future I can tag or link or re-file it with ease.
I want storage to be organic - A lot of what goes into my daily journal pages is just braindumping, rambling nonsense that I will not really need again, but it is useful to get out of my head in the short term. However, some of what I write I will need in the future. For this, I want a system that supports a thinking-adjacent process - the things I give a little more thought towards (or in Logseq, I re-read and tag or link them) are more likely to get surfaced in the right future context, and the things that represent minute-to-minute stream of consciousness sink away (but remain on disk as a more traditional static journal).
I want storage and retrieval to be the same action - Let’s say I’m mentioning a person in my notes, and maybe that person has a page, maybe they don’t. In Logseq, I just type [[ and start typing the name. If that person has a page, it pops up and I can even Shift+Enter to open it, and if not I type the full name out and boom, some reference is stored, which can also be opened and typed into in the same inline action as retrieval. A similar workflow is possible in Emacs.
I want retrieval to be frictionless - If I vaguely think some piece of information exists in my notes, I should be able to find that piece of information if it exists or know with certainty it does not exist within as few keystrokes as possible. For me, this manifests as the full-text search available in both Logseq and org-roam, the host of queries embedded in my right sidebar in Logseq, and the “Linked and Unlinked References” section of every page.
I want retrieval to be organic - My brain doesn’t take linear routes through information, especially when writing, reading, or other more creative work, but some information is still very structured. Systems like Logseq and org-roam support keeping, and more importantly finding, very structured information (like contacts or article notes that have fixed, specific metadata), as well as linked-together emergent webs of less organized information, like concepts I found interesting or personal writings.