there's no reason we couldn't support it, we just don't at the moment 🙂

there's another reason we don't use folders

dendron allows you to refactor your notes and schemas at any point. this means that any given note can either be a file or a container at any point

having all files be notes makes this trivial whereas with folders, we now would have to create an

index

scheme if we wanted to refer to the folder

whats a container

by container, i mean something that can hold files

(aka folder)

see this for why we stick with the flat structure: https://www.dendron.so/notes/f3a41725-c5e5-4851-a6ed-5f541054d409.html#whats-with-the-s

ok so why you need

index

if they are folders

if they are semantically same

lets say you have

lang.python

as a note in dendron

that is stored as

lang.python.md

and you can just open it

if it has children (eg.

lang.python.flow

) then you can just open that as well and there's a parent child structure between them

so if I create a new layer to a note (new folder)

move everything up a level

if

python

was a folder,

lang.python

would need to be represented as

lang/python/index

or something like that in the file system

I create

lang.python.flow

lang/python/flow.md

gets created

dont see a problem

oh i see. you mean having the file alongside the folder. yeah, you're right, that would also work

thats what I do now and like

as otherwise this would be a mess

even if I do

.

things

and I like https://github.com/nikitavoloboev/knowledge/blob/master/SUMMARY.md as it gives the order of how things get rendered

I assume dendron has something similar to summary.md

i would say there are two causes for dot notation: 1) this is how it was built and so we haven't updated that 2) dendron's hierarchy approach promotes having very sparse hierarchies for just in time learning.

eg. lang.python.data.dict

might be the only entry in your python hierarchy

with files, its one file. with folders, you end up creating lots of empty containers

never an empty container