@User message pack definitely looks leaner in terms of serving as a transport packet. i think we're okay though because the json is mostly for caching and storage on startup/shutdown. for plugin integration, we are planning on migrating the dendron engine from a library to a language server protocol. at that point, it will probably make sense to use message pack and open the doors to all sorts of editor integrations

Iirc, lsp is json rpc, so keeping json as the exchange format everywhere might make sense also in the future

> @User > i've had a number of questions regarding whether we can remove the frontmatter and have created a ticket that will store frontmatter outside of a note: https://github.com/dendronhq/dendron/issues/160 > > let me know if you're interested in this and I can make a list of changes necessary @User

We ran across a similar crossroad in Leo, (which you can think of as a programming editor that lets you take a guillotine paper trimmer to your source file(s) to form small, [named or anonymous], hierarchically-compose-able, code sections). To put it in Dendron terms, each file is a vault, each section, (==note), has its begin/end indicated by leo-specific "markup" that is "hidden" from the interpreter/compiler/VM by just commenting them out with whatever comment delimiting character for the language being used. Makes for a lot of distracting comments when you look at the file with a regular editor. They came up with a scheme that used two directories, one with all the files cleaned of the leo markup, one with. So a save from Leo wrote each file twice, and logic had to be added to detect edits made outside of Leo that had to take those edits and try to reconcile to existing sectioning. This stuff is still in Leo but little utilized as "auto-sectioning" routines where made for each language that are "good enough" to get you started, and can be slipped when you want finer, more deliberate sectioning.

Towards relating this to what under discussion here, (e.g. removing frontmatter to a central single-file store, --ala windows registry--), there were a lot of headaches with it and corruption potentials add for little gain.

For what I'd like to do, (allow Dendron to use other markup system, --ReST, Assciidoc,MyST,ect--), I'd keep the frontmatter meta-data with the file as is where it causes no problem, (think asciidoc allows it), and where it would cause problems, --e.g. Rest at least--, place it in comments and just add logic to dendron to write and read the YAML in a "comment proctected format" that would be activate by file extension in force for the vault we are working with.

> Iirc, lsp is json rpc, so keeping json as the exchange format everywhere might make sense also in the future @User got it. i wasn't sure if they supported alternative formats but in that case, we'll just do json rpc

@User appreciate you sharing your experience with leo. i can see how the reconciliation of metadata can cause headaches, especially given that these are all local files that can be edited outside of dendron in a normal note taking app. my bias is for sticking metadata in the frontmatter which means that your note is also completely self contained within itself. that being said, i'm still open to having the option of externalizing the metadata. it's not high priority work for us but i'm not going to stop others from taking it on 🙂 currently, markdown is hardcoded in a few places inside dendron. this is something i would eventually like to be made into a configuration. this is a good document to look at in terms of the dendron architecture https://www.dendron.so/notes/c160ddce-edec-4f6e-841b-418d6030fa37.html

> my bias is for sticking metadata in the frontmatter which means that your note is also completely self contained within itself. that being said, i'm still open to having the option of externalizing the metadata. it's not high priority work for us but i'm not going to stop others from taking it on 🙂 @User As "Head Gardener" you've only got a finite amount of time and attention, so this makes sense.

yeah, prioritization is definitely been a challenge. there's a hundred different directions we could go so having a clear roadmap while also having room for community requests has been top of mind for a while now. to that end, we will be coming out with a more comprehensive roadmap before the end of the month that will help with that

Why you decided to publish dendron as a extension and not as a Electron based app. Because you have 4-5 extensions on VS code. And VS code looks intimidating to common user. I think appeal of dendron will be greater if it is available a standalone app. I am a common user myself with no experience of programming.

it came down to prioritization. i started off building my own electron app that was similar to obsidian but realized i was spending most of my time building the undifferentiated scaffolding for yet another note taking tool. with dendron, I wanted to promote this hierarchy first approach to note taking and focus on the features that I didn't see anyone else doing. https://www.kevinslin.com/notes/3dd58f62-fee5-4f93-b9f1-b0f0f59a9b64.html i agree that vscode is intimidating to non-programmers (heck, even to progarmmers at times 😅) but the tradeoff here is ~6months of development time, probably more. this being said, the core dendron engine is not vscode specific and there are folks that are experimenting with porting it over to other editors (eg. sublime, vim). we also have a standalone editor for dendron in the roadmap though that probably won't happen until well into next year

So, no plans for standalone app then? Because neither sublime nor vim are used by regular users.

> we also have a standalone editor for dendron in the roadmap though that probably won't happen until well into next year

Well, still one possibility: create stripped down version of vscode optimized for dendron and note taking.

A bit similar what jetbrains is doing e.g. with intellij vs pycharm

The experience for regular users could probably be greatly simplified, and this might be much faster route to get there

...but its still a substantial amount of work, so good idea to evaluate if it really makes sense

yep. the easiest path forward to a slightly better user experience is using a modified vscodium (https://vscodium.com/) this lets us create a vscode editor with dendron and related extensions already pre-installed and hopefully hide the no-essential features (eg. debugger, etc), at least from the ui

plus it lets us do additional customizations like hook into the quickinput widget (the thing responsible for the lookup) and allow for lookups where the cursor is already at the end of line (save the extra right arrow key which we have to do today because highlighting is the only available interaction via the api)

For my part, i switched over from Zettel to dendron exactly because it is just an extension. I love it! I understand that this is not for everyone and if there is a need for an all-in-one package, I think could could be a good "community version". This would allow @kevins8 and the core team (is n>1?) to stay more focused. Just my 2ct

having some sort of standalone editor is on the roadmap. probably a 2021 item

2021 is not far though 😆

We can wait for that, looking forward to it!

@User a couple of questions related to the codebase: 1) what kind of use cases you currently have in mind for the note ids (uuid) which don't work with the "path ids" (some.note.in.the.hierarchy). 2) I believe schemas currently somehow rely on the concept of domains, however what would happen if there wouldn't be a separation between the domains and any other level in the hierarchy?

@User > 1) what kind of use cases you currently have in mind for the note ids (uuid) which don't work with the "path ids" (some.note.in.the.hierarchy). - uuid are currently used to uniquely identify a note. this is mainly used for publishing to make sure the note link will stay constant even after renaming: https://github.com/dendronhq/dendron-template/blob/master/vault/dendron.topic.publishing.md#permanent-ids - otherwise, uuids are a hedge against future features that might make the path name not unique (eg. multiple vaults with the same paths though i supposed that could be mitigated by prefixing the vault) > 2) I believe schemas currently somehow rely on the concept of domains, however what would happen if there wouldn't be a separation between the domains and any other level in the hierarchy? the implementation for schemas is pretty simple right now - it constructs a glob pattern based on the 'root' of the schema and will match any hierarchy that matches that glob pattern. its related to domains in the sense that my convention has been to do one schema per domain. but with schema imports, you can also just construct an arbitrary schema, include it in an existing schema, and call it a day. for example, see the journal schema which is used inside the project schema: https://gist.github.com/kevinslin/5ca7a6f25a239add5ea374f329e6a19e i still own your an rfc about terms. i haven't forgotten about that. 😅

Thanks @kevins8 , makes sense 😊

@User continuing conversation here since it's mostly dev related

Below is a dump of notes that should help you get started: - setting up dendron dev environment locally: https://www.dendron.so/notes/64f0e2d5-2c83-43df-9144-40f2c68935aa.html - part of the code that is dealing with refs: https://github.com/dendronhq/dendron-template/blob/master/vault/dendron.dev.design.engine.md#parsing-note-references - note refs doc: https://www.dendron.so/notes/849ee8ee-05a5-47bf-b44d-d7c257117bc4.html#parsing-note-references - thoughts on implementation: currently, refs have the following format (newline for sake of clarity)

((
    ref: [[foo]]
))

assets in dendron are typically stored under {vault}/assets by convention. they have typically been accessed using markdown links

- [some asset](/assets/foo.png)

for referencing assets, we will want to extend refs to handle new file type

((
    ref: [[/assets/foo.png]]
))

- modify

parseDendronRef

to be filetype aware (currently it just assumes markdown) - modify

dendronRefsPlugin

to handle other file types

created a tracking issue here: https://github.com/dendronhq/dendron/issues/190