For anyone who is using folder note, I’ve published a new folder note plugin with many huge improvements, which is currently pending reviews: aidenlx/alx-folder-note
FYI, your wiki page on the different strategies is incorrect regarding the cons of the inside-same strategy: you do not need to use
[[myFolder/myFolder]] to link,
[[myFolder]] is sufficient if you only have one note named
You may also wish to add to the Pros of that style that it’s compatible with the Note Folder Autorename plugin, which users may prefer if they’d rather move or rename the note than the folder. (As notes can be moved or renamed using keyboard commands, unlike folders which require mouse operations on the explorer view, or else Quick Explorer.) In addition, Quick Explorer supports the inside-same folder note strategy, by showing previews of the folder note as a preview for the containing folder, so that might be another pro worth mentioning. (Of course, I might be biased, since I wrote both NFA and Quick Explorer. )
Last, but not least, it might be a good idea to include some indication in your README what the differences are between this and other note-folder plugins. It isn’t immediately obvious what your plugin does that one can’t do with xpgo’s folder note plugin for example.
(After a bit more examination it looks like the main thing the plugin adds is the vfolder block syntax, but it’s not clear to me that it couldn’t be just a plugin that provides vfolder blocks, since the vfolder syntax could be useful on its own without any of the other features, and I assume it could be used with xpgo’s plugin to get the renaming and file explorer parts.)
FWIW, I find @aidenlx’s plugin really intuitive (much more so than the original). It’s easy to create folder notes from the context menu (right clicking on the folder), and it is also very easy to specify what YAML field I want to display on the “summary cards”.
So, ended up using this plugin a lot.
This is not to say that the original one is not helpful, it’s just that this one definitely has its place.
First, thanks for your suggestion on the pro-con comparison. It’s mostly adapted from xgpo’s without too many changes.
This feature is already covered in my plugin, so I will add a warning about this.
TLDR: alx-folder-note is a maintained, completely rewritten, and improved folder note plugin that covers all core features of the original folder note (except folder overview), with enhanced file explorer patches and lots of QoL improvements, aiming to make the folder with note work as seamless as native files.
foldverv is actually not the main purpose for the new plugin. The reason for the new folder note:
- At first, I implemented several improvements as a pr on the xpgo’s plugins such as keep folder with folder notes collapsable on file explorer. But as I continue, I found that my implementation is basically a complete rewrite of the original plugin, as I move on to patch file explorer core plugin directly instead of dom patch in the global window, which is quite unreliable.
- it seems that the xpgo’s plugin is no longer maintained and the author has disappeared from the community for quite a while
- the plugin is without any license, so no forked version, no new features without author’s permission unless rewriting a new one
The major improvement is that it allows auto-hide on folder notes, while original plugin hides only if you click on the folder, as well as classes to folder item to allow styling on folder in file explorer with linked note, and many QoL improvements. Also, API is exposed for other plugins.
I’ll talk about this in the discord, I have a very similar plugin and I think we may be able to collaborate
I’d prefer not to try to do this via discord; the bandwidth is too low unless synchronous.
As far as collaboration goes, my philosophy of plugins is that as much as possible, they should be small and aimed at synergy with other plugins rather than taking on all possible aspects of a task, especially if it results in a lot of UX choices that different people may not agree on.
This is especially true when dealing with something like folder notes, where the underlying thing is really a convention or agreement of structuring things in a vault, but the specifics of how people want to work with them is different. When plugins combine core functionality with UX extensions in the same plugin, it makes it harder for end users to mix and match features.
My kind of philosophy for plugins related to folder notes is more similar to how Calendar, Periodic Notes, Natural Dates, etc. work together: there is a core plugin (Periodic Notes) that provides configuration and an API for working with it, there are UI plugins you can take or leave, and then other plugins that optionally integrate with that ecosystem.
In the folder note space, it would be nice to have a folder note plugin with slightly more functionality than NFA does right now, with configuration and an API, and file-menu operators for the basic creation and automove/rename of folder notes. Rather than doing any templating, it would instead fire an event to notify other plugins of a folder note being created, allowing them to provide or alter the text. Rather than manipulating the built-in file explorer, it would provide a utility API to get the note (if any) for a folder, or the target path for creating one, so that file explorer extensions don’t have to duplicate configuration and code.
Then, other plugins can exist to change how the builtin explorer works, to provide templates or fancy views, and of course other plugins can use it to provide special features the way Quick Explorer does. Plugins that want to do things involving folder notes would just defer to and depend on this central plugin rather than duplicating the functionality in a mutually incompatible way with one another.
In this way, user choice and plugin flexibility is massively increased, because people can pick and choose the pieces of their solution. For example, templater plus dataview to create default folder notes, and so on, or different approaches to integrating with the file explorer.
My current plan was to create a successor to NFA, Folder Note Manager, with the above core functionality, an npm API, and a way to access that API from other plugins that doesn’t depend on accessing Obsidian’s internal plugin structures or redeclaring types. The specific functionality would be to do what NFA does, but with a choice of folder note strategies, and the option to do bidirectional autorename, not just the unidirectional it does now. There would be another command to unmake a folder note, a folder context menu item to create a folder note (with an event hook for templates or macros), and a file context menu item to turn a note into a folder.
The main reason I was thinking of doing this is that I want Quick Explorer to support creating folder notes, but it’s currently using a hardcoded strategy and I really don’t want to end up with a monolithic thing that forces one strategy or competes with other choices in this area. So my thought is that by making FNM (folder note manager) to implement a mostly-UX-choices-free system for managing folder notes, then QE and other plugins can build on top of that.
Agreed, I’ve already worked like this when developing breadcrumb-nav, access plugins via API. I’ve even submitted PRs for dataview api types. For folder note, the code structure is rather modular so it should be easy to be migrated. But Licat will has some work to do to make users less confused when there are so many options available . So I’ll create a parallel project like
folder-note-core and migrate the code to there. Most of the functions you need is in commands.ts, find.ts and vault-handler.ts, I’ll invite you as a collaborator when the repo is created.
And for Quick Explorer, is it possible to collaborate so that I can migrate some features from my project to yours, like support for breadcrumb syntax? The relation-resolver is implemented similar to your idea. I won’t have too much time to maintain so many dedicated projects in the future so I think it’s better to get them working on Quick Explorer.
For folder notes, I thought my previous comment was clear: at some point I will be making FNM with the features I described, unless somebody makes it first. I’m not interested in direct collaboration on any project, just co-ordination between projects or the occasional PR. Or if your folder-note-core provides a sufficient API and features before I get around to it, then there’s no need for me to write FNM and I’ll just integrate with that. Otherwise I’ll get to it when I get to it.
Regarding breadcrumbs, I’m not sure I follow how that would integrate w/QE. QE does folder navigation, not link navigation, and I wasn’t able to find any documentation or information on your nav plugin or relation-resolver outside the code itself, which I don’t have time to dig into at the moment.
Got it. Will send you the link when folder-note-core is available.
For breadcrumb-nav, it’s still under development and the document is not ready yet. A demo video is already sent over discord. In short, it can display virtual paths based on inline fields inside notes (like
parent::[[some file]]) that do not exist in the file system. It can use folder note to as a bridge between virtual path and file path, for example, put all notes under a folder with linked note and specify hierarchy in notes without actually create folders.
I believe I saw the demo, but I still don’t understand how it works or what it’s for, let alone how it would interact with QE. I have thought about adding a feature to QE to allow browsing a file’s links or backlinks as a submenu, but I doubt that would really replicate what you have in mind, even though I’m not precisely sure what it is you do have in mind.
Now that I’m thinking of it, being able to navigate to the tags in a file, and from tags to the files that contain them might be cool too… ah well, something for later. If I figure that out, then I might be able to come up with a way to define other virtual paths for the breadcrumbs, and thus support your breadcrumb model, whatever that is.
But that is some ways away, as right now QE is very tightly coupled to having menu items be file/folder objects and a fairly rigid navigation hierarchy.
Currently, Obsidian sorts folders and files separately.
The Alx-Folder-Note plugin could benefit from “Same sort order for folders and files”.
Because “folders~notes” can be worth the place of a note within a tree structure.
I believe Trilium allows this kind of sorting.
Wikipad has a tree structure by nodes.
This is up to everyone’s preference, but one can benefit from such an organization of things.
Is this a possibility taken into account in the evolution of the Alx-Folder-Note plugin? Or more generally Osidian, or a plugin specific to triage?
Thank you for bringing us such a good plugin, I would like to know if it is possible to “move note to this folder” while “make note to folder”? This feature can be implemented by Note folder Autorename, but it doesn’t work on iphone. I look forward to your reply!
I’m suuuper late to the party, but thank you so much for working on this plugin!
Thanks a lot for the plugin, it’s really practical for some of my folders.
There’s one thing I’m wondering, is there a way to affect the colors used by the headers in the cards vault-wide ?
I understand it’s possible to do card by card in the ccard syntax but I can’t find a way to do it for all cards generated by the plugin.
For example this red background doesn’t fit with my theme at all, but I don’t know how to change it. The rest of the colors seem to be affected by the theme but not this one.
How do you get dataview to ignore the folder note in queries?