dendron

dendron copied to clipboard

Proposal

Change Dendron to use folder hierarchies instead of the dotted filenames (that are currently used).

The reasoning for this is described in Dotted filenames vs. Folder hierarchies

I tend to disagree. I'd prefer if the current approach remains available. Maybe it's something to be made configurable.

It would be nice to have command to auto convert dotted <-> folder hierarchies.

Folders would be great with possibility to store reference files in them, not in assets folder.

Big support from me! this is currently one of the major limiting factors to me using Dendron mostly. I use Directory Opus on windows and it is customized heavily so I am very dependent on folders.

Proposal

Change Dendron to use folder hierarchies instead of the dotted filenames (that are currently used).

The reasoning for this is described in Dotted filenames vs. Folder hierarchies

The link posted no longer works. Can the argumentation be added to this issue?

I never saw the original link, but I would like the ability to use folders as that's how I organize my materiel across computers. Folders are workspaces that contain more than just md folders. they have subfolders with csvs, code, docx, etc. I use Johnny Decimal and directory opus to achieve colorcoding like so

I think the link is this one: https://wiki.dendron.so/notes/da241d31-8a05-429c-a041-02ac6170bf20.html

+1 for the keeping and maintaining the current solution of dotted file names.

Don't see it as an either/or! Both would be ideal ; I would love to have certain folders have certain hierarchies

In case of the folder hierarchy, how would note containers be implemented where a note can serve as a folder but also contain information?

Going to add another vote to the "leave as is" pile. Dendron's use of . to signify hierarchical levels, along with making text files analogous with folders, is both one of its unique features as well as one of its strengths. It makes it very easy to find a file, even outside of Dendron, because everything is in one location and file names follow a uniform set of rules.

While it would certainly be ideal to allow each user to to choose their own preference, I do not know how feasible that would be to pull off. At the very least, I expect it would require a rework of both Lookup and its related features, as well as a rework of the Dendron Tree View. Furthermore, I do not see how this could be made togglable. Most likely a user would have to choose one or the other when initializing a Dendron workspace.

While not a perfect replacement, it seems something similar to a folder-based hierarchy could be achieved with use of the Multi Vault feature.

As another alternative, possibly an export option could be implemented that converts the . hierarchy to a more traditionally folder-based hierarchy, but as has been noted above, there is still the issue of converting the "folders" that are also active text documents.

My two cents, anyway.

AzureDevOps wiki also has "file and dir in one". Looks like it just keeps Foo dir and Foo.md beside.

along with making text files analogous with folders, is both one of its unique features as well as one of its strengths.

While I agree that the hierarchical approach is a strength, to me as a user the implementation is completely transparent. I don't care while in editor if it is implemented in file or directory. I don't see why using files as opposed to folders is "considered a strength" while on the perspective of the hierarchical approach.

At the very least, I expect it would require a rework of both Lookup and its related features, as well as a rework of the Dendron Tree View.

As outlined in the attached pro/cons overview, one could argue that you don't need the Dendron Tree View.

Furthermore, I do not see how this could be made togglable. Most likely a user would have to choose one or the other when initializing a Dendron workspace.

The solution previously mentioned seems to be a script that auto-moves the files when swapping. A solution could also be that the lookup attempts to resolve to both locations simulteanously on certain requested types of lookups (link resolvement), where the order of resolvement is what you toggle between.

While not a perfect replacement, it seems something similar to a folder-based hierarchy could be achieved with use of the Multi Vault feature.

My main perspective on this issue is that the hierarchical structure is getting in the way of readability of the files in the file explorer. Or more importantly, hierarchy among files is naturally denoted by folders and a lot of plugins interacting with hierarchy depend on this assumption.

Using a folder based approach would make a hierarchical approach in notes less Dendron-specific and better allow interaction with external tools. (E.g.: https://github.com/dendronhq/dendron/issues/210#issuecomment-808915933)

Since moving to Dendron, one of the things I'm really not happy with is mobile access... and the biggest issue there is having 2000 notes in 1 folder, where it takes dozens & dozens of swipes to get half way down the list, never mind the bottom... sure there's search, but with that many notes, it's often more helpful to just get to the right folder

Some updates on the folder issue. I definitely agree that the UX with existing tools is not great when you have a folder with thousands of files. Here's where we are on the folder issue:

• implementing Dendron with folder hierarchies is possible but currently not on the roadmap unless someone from the community wants to take it on
• as a compromise, we do have a markdown export pod ( https://wiki.dendron.so/notes/ccab31c4-e9ca-4ee8-b754-f786a3f3be6e.html) and one feature that's coming soon is the export dendron hiearchies as folder hierarchies so you can use it with existing tools
• in the future (aka sometime this year), we'll also offer Syncronization Pods which let you keep your data from Dendron in sync with another destination (think of this as a continuous export pod)

On Sun, Apr 4, 2021 at 7:34 AM John Meyer @.***> wrote:

Since moving to Dendron, one of the things I'm really not happy with is mobile access... and the biggest issue there is having 2000 notes in 1 folder, where it takes dozens & dozens of swipes to get half way down the list, never mind the bottom... sure there's search, but with that many notes, it's often more helpful to just get to the right folder

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dendronhq/dendron/issues/210#issuecomment-813043762, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABPIPV6ZENJ2BDZEYOTLJTTHB2I3ANCNFSM4RPHQPWA .

I might be talking nonsense, but is it possible to make a fake folder structure by symlinking dotted note files into a scaffold of empty folders? This could be used in a sort of "read-only" way where an external tool (mobile app, for example) can read and edit existing files, but can't create new ones or delete anything. Dendron would still have to create and maintain the folder structure (maybe the export logic to plain markdown can be reused here), but this would give better access to notes when used with other apps. I realize, though, that this approach is neither here, nor there without the ability to create/delete new files through the external tools.

Its possible though at that point, the complexity would approach supporting folders. For a read only version of Dendron with a folder structure - that is planned to be supported for the next iteration of the Markdown pod: https://wiki.dendron.so/notes/ccab31c4-e9ca-4ee8-b754-f786a3f3be6e.html

On Mon, Apr 19, 2021 at 10:04 AM Aleksey Rowan @.***> wrote:

I might be talking nonsense, but is it possible to make a fake folder structure by symlinking dotted note files into a scaffold of empty folders? This could be used in a sort of "read-only" way where an external tool (mobile app, for example) can read and edit existing files, but can't create new ones or delete anything. Dendron would still have to create and maintain the folder structure (maybe the export logic to plain markdown can be reused here), but this would give better access to notes when used with other apps. I realize, though, that this approach is neither here, nor there without the ability to create/delete new files through the external tools.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dendronhq/dendron/issues/210#issuecomment-822628744, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABPIPXKQCZJIXUDRA2DB63TJRPA5ANCNFSM4RPHQPWA .

Just started using Dendron, this is one of the first annoyences I have encountered. Don't know if it is a workflow thing, but it's a real obstacle to organizing when I have external programs, like latex, R, and cad files. I have to manually maintain a semblance of matching hierarchy in the asset folder, to match the dot hierarchy files in md format for the tree view. This is due to the tight coupling of my assets and the notes in the two places, since my notes are usually about my files or vice versa. Having a good interop with external programs and be more open ended, instead of closed down on it's own format, would be a big improvement IMO.

I second this on the caveat that it doesn't need to replace them or be a binary choice. Support both it shouldn't be too hard and I can see folders being used to separate complete categories and dotted file notion to be separating within said category.

E.g

Folder: Recipes
grilled.chicken.tenders
grilled.steak.wagyu 

Folder: Workouts
biceps.curls
biceps.chin-up

I am not going to argue against the one or the other approach. But at least a basic mixed mode is really desirable/urgently needed. Let's say I want to put all sections of a chapter in a folder but then the sections themselves can follow the dotted hierarchy. Then multiple chapter directories could be grouped in a volume directory.

I think the main reason to support folders would be the simplicity of working on notes from other applications. Now, don't think about the case of importing, think about the case working with both.

For instance, I like Obsidian and Dendron. I'd like to work on the same notes with both. Yet Dendron doesn't work with folders as Obsidian.

I use Obsidian only on mobile and there it works absolutely fine with the hierarchies

I would also like a folder view - will be easier also when integrating 3rd party tools ,for example for mkdocs compatability etc.
dot notation is super easy when creating in command pallet so I would keep the syntax intact

Myself and others don't like the assets folder as a catch-all for related non-markdown files. E.g.:

Folders would be great with possibility to store reference files in them, not in assets folder.

I have to manually maintain a semblance of matching hierarchy in the asset folder, to match the dot hierarchy files in md format for the tree view. This is due to the tight coupling of my assets and the notes in the two places, since my notes are usually about my files or vice versa.

Having hundreds or thousands of notes forced to share and reference/link into a centralized assets directory is sub-optimal for various use-cases:

• Poor interoperability with other tools that open projects/things from a single parent folder context. E.g.
  • VSCode iself is very effective when opening a single folder and showing a focused view of the markdown note and related files if they're within the same folder.
  • Denron's disjoint assets folder breaks this useful way of using VSCode to look at other content related to the note, e.g. source code or jupyter notebooks.
  • It's cumbersome to navigate to and use related content with standard filesystem tooling if it's not located nearby.
  • Popular markdown note taking tools like Obsidian or Zettlr support directories and play nicer with each other and VS-Code.
  • Yes, user beware, if you fiddle with or refactor the note outside of dendron, dendron can't automate and relate the changes throughout the other notes.
• Filesystem indexing and search tools will find notes and related content scattered and somewhat out of context.
• Standard filesystem copy and sync utils won't work well either. How do you know you've copied your note and it's all related files? Can't use a simple filesystem manager, you now have to take care use dendron export features or micro-manage things as separate vaults.

This design choice of dendron making notes and related file content live in a disjointed way is similar to the reason I was put off by Joplin.

As the most recent comments appear to have less to do with Dendron's use of the dot filename hierarchy and more to do with its handling (or, uncharitably, its lack thereof) of non-Markdown assets, I have created a new issue to continue this direction of discussion: #3556 Better Handling of non-Markdown Assets in Dendron.

I invite all Dendron users to share their thoughts regarding the Assets folder there. Let's keep this proposal on topic.

@micharris42, thanks, I appreciate the nuance that point out with the concern actually being about how it feels awkward to maintain non-markdown assets.

I imagine the idea to hide all the assets away in a shared assets dir was to keep focus on the dot-delimited note files in the VSCode explorer view. This design-choice possibly happened early on, when the author was taking notes directly in VSCode before his method turned into an extension. This choice also made it much easier to quickly find notes with a simple filename search while coming up with a strategy to manage notes in VSCode directly using the Explorer.

As per https://wiki.dendron.so/notes/683740e3-70ce-4a47-a1f4-1f140e80b558/#hierarchies, one concern was that folder hierarchies "ossify":

The traditional failings of past hierarchies were that they were too rigid. Most people’s experience with hierarchies are folder hierarchies that ossify from the moment that they are created. These hierarchies are hard to change and so people don’t change them, even as their underlying understanding of the domain changes.

However, if a custom explorer view is integrated into the note taking tool/extension, then moving (via drag and drop) or renaming notes and other refactoring could in theory recurse and update references in all notes affected by the change. And this custom explorer view could filter/de-clutter the view to just show notes, or have a toggle to expand out to show related asset files.

I think this is easier to unpack with examples.

E.g. current:

assets/icon.png
parent.md
parent.child1.md
parent.child2.md

Which note does icon.png belong to? You'd have to read over all .md notes to find ![](assets/icon.png)

E.g. possible alternative:

parent/icon.png
parent.md
parent.child1/icon.png
parent.child1.md
parent.child2/icon.png
parent.child2.md

Now it's possible to have notes and related assets more clearly split and associated. BUT, linking them in as images in markdown is going be more painful using long dot paths instead of short relative paths. E.g. ![](parent.child2/icon.png). And renaming refactoring the note hierarchy implies changing the asset dir and references to assets within the notes.

Another alternative:

parent/parent.md
parent/icon.png
parent/child1/child1.md
parent/child1/icon.png
parent/child2/child2.md
parent/child2/icon.png

Now image/asset linking refs are short like ![](icon.png). And refactoring it means the relative assets travel with the note, so there's no need to go hunt for and update link references to assets in the note. And if an asset is shared/used by both child1 and child2, then the appropriate place for it would be the parent folder, e.g. ![](../shared_icon.png), but care would need to be taken with refactoring notes that cross reference shared assets.

One bit that is annoying to have the repetition of the note filename and folder e.g. child2/child2.md, but maybe the UI could just prompt the user to create the note as parent/child2 and it generates the file at parent/child2/child2.md. The the UX experience of note hierarchy being parent.child1 vs parent/child1 is just a . vs /, but in this way, dendron could be more directly interoperable with keeping related material in a folders, and both Obsidian and Zettlr handle/apply this kind of folder approach to provide hierarchy. E.g. the explorer tree view would not show raw files, but rather a trimmed hierarchy:

parent
  child1
  child2

@JPvRiel, thank you for your expansion of your initial comment. Would you be willing to copy this over to #3556?

Looking through this full thread, there seem to me to be two major drivers for a more traditional folder hierarchy:

1. Interoperability with other tools, be it Obsidian, Zettlr, or even just the default file explorer.

2. Dendron works very well with .md files, but not so much with anything else.

While these two are not unrelated, I do not think that Dendron's handling of non-Markdown assets necessarily requires a switch from the current dot filename hierarchy to a more traditional folder hierarchy.

If Dendron treated all files the way it currently treats Markdown files, then something like:

parent.md
parent.icon.png
parent.child1.md
parent.child1.icon.png
parent.child2.md
parent.child2.icon.png

Could work. Get rid of the assets folder entirely, and use Dendron's existing refactoring commands to manage notes and assets together. Autocomplete would address pains with particularly long file names. Rather then introducing new tools, this would just require beefing up Dendron's existing feature set.

Of course, it could be that the best way to improve Dendron's handling of non-Markdown assets is to adopt the traditional folder hierarchy. I cannot say either way, which is why I think moving this discussion to its own dedicated issue #3556 is more likely to lead to a result.

Adding my vote to having folder hierarchies as a configurable option. The more I use dendron the more visual clutter I get in the File Explorer panel, and I think people should have the flexibility to use an organizational system that suits them best. Yes, the Tree View does what I'm looking for but then I lose the ability to see notes that I've recently created/modified from the git status highlighting in file view. Though having the Tree View show git status highlighting might also be a simpler solution?

I know this would be lower priority but could someone from the project comment on what it would take to implement this?

Thanks