custom frontmatter attribute, this would be the

area

in the PARA system

$.

is shorthand for querying properties in the frontmatter

this seems like a way to work with structured data I thought roam queries were more like "find me things that mention both X and Y"

yeah, that's what all the examples show. i guess when i say roam queries, i just meant materializing queries inside of existing notes

@User > Moving from files to folders will be a significant development effort True, that's why it's good to think this through before LSP. If it's not done along with it, it's probably better to not do it later either. > ...without any immediate change in functionality If this task would be initiated, it would probably be a good idea to think also e.g. should non-markdown files live within the same folders, be part of the lookups etc. This actually would bring additional functionalities to the table from day 1. > if we do switch to folders, is it worth keeping the . syntax at all? Good question, the biggest obstacle might be the conflict resolution. E.g. if there's foo.bar.baz.md and foo/bar/baz.md, which one wins? Personally I'd keep it clear cut and always use '/' as the path separator. This naturally would require migration of the existing data into the new structure (both renaming & copying the files + changing the links). > can you create an issue for this as well and link it to the design docs? Sure: https://github.com/dendronhq/dendron/issues/210

@User i've thought about this a great deal yesterday and here are my thoughts: 1. i think supporting folders and files make sense. we should do it for all the benefits you've outlined 2. i think we will need to support both

.

and

folder

based hierarchies concurrently for at least some period of time - i've been part of many a software migration and they always take longer and are more complicated than initially thought - we're planning on doing the lsp migration in october and i don't want to change two major components at the same time (some call it an opportunity but they usually turn out to be quagmires) - migrating to folders will affect all components in dendron including third party extensions; this will take time and is best done one at a time. instead of doing it all at once, we can migrate components one by one. 3. we can have a configurable toggle 'dendron.folderSupport` and set it off by default

i think we will need to support both . and folder based hierarchies concurrently for at least some period of time > Does it mean we could have different

folders

in the same vault?

yep

@User Sounds intriguing! The LSP task is probably worth of some kind of breakdown, since e.g. "markdown notes"-related functionalities are at the core of it - meaning should markdown notes be gone at the same time with the LSP? To me the whole LSP related activity looks a bit like switching the foundations of a house (in comparison to e.g. changing the roof). However I'm glad if proven wrong 🙂

There's also two approaches; one keeping the dendron extension going all the time in single branch and somehow gradually bringing in the LSP. The other is to slam it into own branch for quite some time so that the whole implementation can be switched at some point. Looks like Foam is probably doing the latter, not sure how difficult the former would be in case of dendron (at least I wouldn't expect it to be easy)

@User yeah, it's definitely a bigger ticket item. here's a super rough breakdown: - create

@dendronhq/lsp-server

package - create interface btw lsp -> engine - implement a basic new feature using lsp (eg. hover preview of link) and delegate to lsp - route basic old feature to lsp (eg. go to definition from markdown-notes) - everything else

@User I guess that would mean that during transition period, all markdowns are parsed at least three times (server, extension, markdown-notes)

yep. would not be pretty but transition periods aren't and as long as it doesn't impact the user experience, it should be workable

@User fyi, update on the lsp work. i've updated dendron's architecture diagram to reflect the lsp and some other changes: https://www.dendron.so/notes/c160ddce-edec-4f6e-841b-418d6030fa37.html#architecture biggest change from what we've originally discussed is that Dendron will not have one but two servers: one lsp server and one express server. found the express server to be necessary because trying to make the vscode language server do anything besides lsp is an exercise in frustration. the lsp server will call into the express server to query the engine. any lookup specific non-lsp functionality will be queried by the extension directly. what's nice about having a standalone local server is that it opens up the path for any longstanding non-lsp related tasks (eg. the pod

sync

feature I was talking about). it will also make it relatively straightforward for any other extension to integrate: instead of having to use a language server client, they can query the server using a traditional REST client. what's nice with this model is that this architecture also migrates well into any standalone/cloud hosted versions of dendron we might pursue in the future.

interesting. Sounds like a fun thing to debug 🤔

any other extensions doing the same?

i don't know 😅 it's a pretty standard webapp architecture but don't know if i've ever come across extensions doing this

yeah, I just remember that getting the extension to connect (attach) with the lsp server during debugging was already somewhat of a hassle. I could imagine additional server doesn't make it any easier 🙂

what happened with the custom rpc messages with the lsp server?

it's actually easier to debug as a web server since debugging an express server is pretty common in vscode. it's also easier to test standalone since its just testing a normal web server. for custom json rpc, i spent only a little time looking into it but didn't find a builtin way of using the vscode-language-server/client to send custom messages without monkey patching.

Looking briefly at the source code, if you get hold of an instance of a BaseLanguageClient, it seems that have

sendRequest

method with flexible params. I think catching these messages should be pretty similar as catching HTTP requests from express (although express is certainly much better documented). IIRC, there was a similar handler on the LSP server side. AFAIK the process of debugging an express-server or lsp-server should be the same (add breakpoint to the server side, initiate from the client as long as the attachment has happened properly). I'd guess that the delegation from extension to lsp to express might be problematic to debug, or at least to establish properly. Anyway, your project and your call how to do it in the end 🙂

that's fair. it's definitely possible to do everything within the language server. the way i'm making design decisions is a balance of forward compatibility (could this work with dendron two years from now when we have standalone clients and browser versions) and delivering results (is this something I can ship within a reasonable amount of time). at the current point, using

express

helps on both aspects which is why i'm heavily biased in that direction 😅 that being said, if this becomes untenable or too much of a kludge, the actual logic for delegating api calls to the engine and sending json responses is the same both ways so it shouldn't be a one way door

(famous last words)

@User even it if doesn't seem like it, I do appreciate and am listening to your comments. you provide a good counter opinion to my designs and if I had more bandwidth, its definitely something I would like to take more time deliberating

so please don't stop. otherwise dendron might end up becoming notion 😅

@User @User if I may comment (please bear in mind I lack loooots of context re Dendron, but I have had similar conversations for foam), I agree with the separation of the two. Having a separate server that runs the "core" means you can do a lot of things even outside of vscode (e.g. if you can monitor file renaming and update links, or you can have a public API on top of the pod, ...). vscode is just another client to your core server

@User your comments are most welcome. having a server definitely gives us a lot more flexibility. it also, as @User mentioned, introduces additional complexity but that's software for you. everything is a tradeoff 🤷‍♂️

@User @User for me it's more about the question "are other LSP implementations doing such a thing" and "if the implementation now tries to tackle the non-vscode use cases, will it be even remotely right when the time arrives and lessons have been learnt". The use of LSP server doesn't limit its use to vscode, since big part of the LSP is it to be re-usable in multiple environments (it just responds to JSON RPC, which in the end is principally the same as express-server responding to REST calls). Also things like file monitoring are not quite trivial to be implemented standalone, since with LSP it's the client who is recommended to do the file monitoring (since if all extensions do it themselves, it might choke the OS). Anyway, I'm not objecting the use of express server, especially when Kevin is doing all the hard work 🙂

documentation note: https://www.dendron.so/notes/9134f160-31a6-4ab0-a640-1fce466f9526.html if dendron works on VSCode it works on VSCodium (I use it & can confirm)