it's relatively straightforward, only downside is that documentation is more sparse than with non-lsp extensions

(and debugging is slightly more annoying due to need of attaching to server 🙂 )

good to know. i might lean on you for guidance and ideas then 🙂 if you get to the lsp doc before I do, feel free to add your thoughts about it as well 😉

i have some experience with lsp - i did skim the docs and went through the vscode bundled lsp examples

also setting up the dev env is a pain, but I guess that is the same with any js/ts multi-module project

yeah - ideally our dev tooling is so good that contributors wouldn't have to worry about it

I wonder if something like rush + pnpm would be any better than lerna + yarn

hmm, didn't know about rush. where i am on tooling - i think more people (especially js) are familiar with yarn/lerna. unless rush gives us some significant advantages, i would be hesitant to switch to it

don't know enough to really comment - I just know that it seems to be hard to get something good up and running 😆

@User interesting discussion on the linking / embedding syntax in Foam's block-references channel - you might want to check it out

> @User interesting discussion on the linking / embedding syntax in Foam's block-references channel - you might want to check it out @User Here is video where jevakallio explains his thoughts

Yup, saw that, it's great

just watched. it’s well done. have to run now but have more thought on this which i’ll post later 🙂

@User @User thoughts on the video. things I liked: - autocompletion and generation of id from the link to the target document - generating an anchor (aka caret) in the end document - having the

#

symbol go to both headers and blocks for dendron, in order to link to arbitrary entries, I've also been playing around with inserting an anchor marker. it's a little bit more verbose 😅

((id: 4832f989-992a-4939-82d2-0165c706edbf))

you would be able to refer to these using refs or links

((ref:[[foo]]id-4832f989-992a-4939-82d2-0165c706edbf))

- [[foo#id-4832f989-992a-4939-82d2-0165c706edbf]]

that being said, i could see dendron also supporting

^

as an alias. anyhow, great video and in general excited to see note taking move forward 🙂

The demo is nice. I liked its paragraph-level autocompletions that help target a particular block. Though storing block ids in markdown content would come with the same editing brittleness as header references in Dendron. This made me think about how offline markdown notes apps promise readability and portability of notes. But all these new features like wiki links, block references and block embeds require nonstandard syntax. An expression like

((ref:[[my.note]]))

is awesome while using Dendron but take the app away and it's just some characters sequence in a text file. Same with any potential

^

-ids. Take the app away and any expectation of continuing to work fluidly with the same notes falls apart because links and lookups and embeds all turn into pumpkins. And they stay that way until you manage to translate all the nonstandard pieces into a format that another tool can digest. So some amount of data lock in occurs even in the "plain markdown files" camp 🙂 Thinking about all these markdown extensions has made me much more tolerant of a new app potentially saying "Yes, we choose to store data in a database to make way for advanced features. Here are our well documented export formats, here's how they preserve ids, links and embeds".

https://www.sqlite.org/appfileformat.html 🙂

one thing that could be done is to store everything into sqlite db while making edits in the editor. That would absolutely minimize all the syntax in the editor and allow all kinds of advanced use cases. Technically it's more involved, but it actually would allow roam-like UI to be created for the same content, while keeping simultanous markdown edits (via vscode) possible.

approach for dendron 2, @User ? 🙂

I had been wondering how much of Dendron’s work could be handled by a wiki/PKM language server, which could maintain the SQLite state you describe. The schema, relationships and hierarchy could be maintained there based on the change events from the editor

I’m not sure how good a fit it is for the knowledge graph visualisation, though... I guess that would have to be exposed via an extension to the langserver spec

> So some amount of data lock in occurs even in the "plain markdown files" camp 🙂 @User regarding lock in, in order to handle note refs and any other dendron specific features, that's where pods come in. the idea is that we'll provide you the tools/apis to parse refs and any non-md compliant syntax so you can export it natively to whereever you wish https://www.dendron.so/notes/66727a39-d0a7-449b-a10d-f6c438185d7f.html#pods-

> one thing that could be done is to store everything into sqlite db while making edits in the editor @User i've been thinking about this. this is do-able and will save as syntax soup. that being said, i still like the idea of having a plain text representation of data. i think we can create another variant of this https://github.com/dendronhq/dendron/issues/160 where dendron will store note specific markup in a db instead

instead of sqlite, i was playing around with elasticsearch. it's a bit more cumbersome to install but has tons of querying/analytics/visualization features. like building on top of vscode to handle all the editing scaffolding, building on top of elasticsearch could be a big boom

@User me too! i'm doing a deep dive on lsp's this weekend so should have a better understanding by monday 🙂

adopting a pet elasticsearch instance is a scary prospect for most people I think))

@kevins8 if it were possible to abstract over ReStructuredText and Markdown and keep the PKM logic elsewhere this could make for a glorious editing experience. I love writing in MD, but RST makes it super easy to throw in the odd table where that’s the right tool

Also, you’re some kinda hero 😆

@User i'm aware of that which is why i've held off on doing that 😅 i want to experiment to see if we can do it transparently (eg. download a binary for your platform, ingest your notes, and handle all the backend crud) so that as a user, you never have to know that elasticsearch is running

think the way publishing works today, but the opposite of that (in terms of ease of use) 😅

oh, so instead of a pet we get a sneaky ninja elasticsearch 😆