we have a #749357067843666032 channel were you can see some examples

i have ~5 schemas that 80% of my notes fall into

--> projects, journal, programming languages, aws

> currently, you can create a subnote out of a current line using scratch notes btw, this wasn't quite what I meant, since it just extracts the line as the note title (?). I mean selecting e.g. third of a note, and "pushing" that to a sub-note via a command

I guess an extension for that would be to lift a subnote as a sub-chapter into the parent note 😄

thanks, I will go to #749357067843666032 As I understand schema's are more like your dictionary files. How do you use TOC or index files? Are they just in the name of the files or do you create something like structured notes (mini TOC) as a file or are these in schemas?

> thanks, I will go to #749357067843666032 As I understand schema's are more like your dictionary files. How do you use TOC or index files? Are they just in the name of the files or do you create something like structured notes (mini TOC) as a file or are these in schemas? @User they are the schemas. i actually don't use TOCs anymore and i'm starting to consider them as an anti-pattern in Dendron since your schema acts as a self updating

TOCs

> btw, this wasn't quite what I meant, since it just extracts the line as the note title (?). I mean selecting e.g. third of a note, and "pushing" that to a sub-note via a command @User now that i re-read your comment, I realize that I was thinking of something else though the later comment of us implementing this in late september still stands 😅

i think the markdown-memo guy actually published a vscode extension that does this in the meantime

here it is: https://marketplace.visualstudio.com/items?itemName=svsool.markdown-kit

yep, that look like a good starting point; however it probably doesn't create the appropriate frontmatter, nor assist by autofilling the existing structure up until the dot. Oh well, I shouldn't ask too much 😄

haha, high standards are good. that's what pushes us to build great tools 🙂

> would be great to have a report that states "these notes probably have too much stuff in them, maybe split?" 🙂 @User @User created an issue: https://github.com/dendronhq/dendron/issues/142. feedback/suggestions welcome 🙂

hmm instead of tree / lookup icons, I'd prefer separate report - a bit like what's shown during structure refactoring. Or now thinking it a bit more, live diagnostic message would be the best (i.e. messages in problems panel) 🙂

...or if it's in three / lookup, should the "problem" propagate up the hierarchy so that it actually gets visible instead of being buried somewhere down below

btw, LSP server would make live diagnostics quite viable

got it. will add that as an option to the issue. might make the icons toggable as well for people who prefer a cleaner lookup/tree view and i like the up propagation of issues. was thinking of also implementing a

coverage report

that would do that (eg. X% of your hierarchy is covered by a schema) and yeah, you don't need to sell me on the lsp. its definitely the direction that Dendron will be taking 🙂

Coverage report would be great. Maybe also something to find potential relations between the notes (e.g. by matching titles against note texts, matching tags, or even some kind of keyword search).

I guess these would be excellent candidates for "dendron plugins", as long as the api is stable :)

stable api will come out after the lsp! tentative timeline is a non-stable api october and a 1.0 around december 🙂

currently, you can build plugins by using the dendron engine in your own project (eg. dendron markdown links does this) . caveat is that each engine instance will re-index your notes so it’s far from ideal 😅

How do you deal with long note names in dendron? For example, when taking book notes you'll probably want to include the book's name. But a note name like

books.surely-you're-joking-mr-feynman.md

looks just too long. And if you then make subnotes for chapters it gets even more ridiculous. On the other hand, if I shorten it to

books.feynman.md

then I'm much more likely to forget how I coded it after a year or so. Not to mention possible name collisions.

i end up doing long titles since the lookup bar accommodates long names. (1) the dendron tree view also helps since it shows the last part of the filename (2) finally, i drag the

open editor pane

down below where I have more horizontal space (3)

I have a bit different approach; I typically just pick the words I most likely will use to search for the note. In this case I'd probably settle for

books.surely-joking-feynman.md

or even

books.joking-feynman.md

. Then in the note title, I'd open it as "Surely you're joking, Mr. Feynman!" (great book btw!).

the title field in the frontmatter can also be used for longer titles. in the future, it'll be possible to search for notes by the title field in addition to the path (you can approximate that today by looking for

title: blah

using vscode builtin search)

(nice thing about hierarchies is that you can scope that search to a hierarchy:

title: feynman

, files.include:

books.*

)

I tried to use Rename Note command to move a note to another place in hierarchy. The tree view got really confused about this: - create note

pizza

- rename to

recipes.pizza

- tree view still shows a separate pizza note, and trying to expand

recipes

gives an error:

Element with id f39efd54-7c3d-4fc9-9cbe-00be9ed0bc2a is already registered

Reloading the window fixes this. Maybe it's not the intended usage of rename command, but imho this should work)

@User I've encountered that kind of behavior too; thus with renames I now always do reindex + window reload. Not the best workflow, but at least it makes it work (like you noticed too)

@User isn't reindexing redundant if you reload the window anyway? )

good question, since I wasn't totally sure I did it anyway. I guess window reloading will re-initialize everything in vscode memory (?), but if there would be e.g. cache files somewhere, those wouldn't be refreshed. There probably aren't any of those in place atm, but eh, better safe than sorry