> the story with vaults is that we currently support 1 per workspace but that should change before the end of october @User I read through the threads about this, as well as the excellent conversation about folders. Would folders would give you the building blocks for (and ad-hoc) vaults? Forgive me if I'm missing something! I haven't looked at the indexer code, yet!

@User folders are just the storage implementation detail but for the purposes of multi-vault, can be considered something all together separate. the dendron engine is responsible for indexing files and currently, it only indexes one "vault" instead of multiple vaults. that was done initially to simplify the implementation below are some links that are helpful to understand the current architecture: - engine indexing logic: https://dendron.so/notes/849ee8ee-05a5-47bf-b44d-d7c257117bc4.html - overall architecture: https://dendron.so/notes/c160ddce-edec-4f6e-841b-418d6030fa37.html

Thanks! I will read over later today. At first blush,

engine.store (FileStore)

is responsible for providing the hierarchical structure?

yep.

engine

is the abstraction interface, and the

store

is responsible for indexing

note that we're currently doing a server migration so the architecture at the end of the month will be.

client -> server -> engine -> store -> filesystem

this doesn't change the

engine -> store

setup

@User, slug v. no-slug ever written out or discussed? (I've searched here, github, and web and haven't seen anything.)

@User we haven't formally written it anywhere so thanks for the reminder to do that. in theory, dendron should be fine with either, but to be conservative, slugging is recommended

Good discussion here: https://github.com/svsool/vscode-memo/issues/16 (I think!)

I reflected on this quite a bit a few nights ago, and the only reason I have for slugs is compatibility with Github's md renderer. I landed on no slugs, but Dendron's use case may be a bit different. The linked issue assumes filesystem as storage. I haven't thought through what happens when you add multiple file stores.

thanks for the link, will give it a read

It's a strange decision to make ... I'm considering using slugs for our team wiki, simply because everyone is used to using Github and having them linked would be a nice convenience (don't need to publish right-a-way). On the other hand, all of my old notes are not slugged and not to impose naming conventions when the filesystem already holds that job.

@User read the issue. the limitations with slugs are real. currently the only hardcoded limitation that dendron has regarding to names is that it lower cases everything when during comparisons (eg. so hello.md and Hello.md would resolve to

hello.md

). don't plan on enforcing slugs at the current moment unless someone convinces me otherwise 🙂 i notice that a lot of static site generators like slugified names due to cleaner urls. dendron generates permanent urls via ids so we don't have that problem: https://dendron.so/notes/5fcb8564-7209-4a80-9bb8-025bc8eb489b.html#permanent-ids 😅

that being said, compatibility with existing wikis like github is also a thing so I would probably recommend people to use slugs unless they have a reason not to

@User This, oddly, is the strongest argument for them.

@User the gravity of legacy weights heavily on all things that come after⚓

Playing w/ VS Code extensions ... spent some time reading the Dendron code yesterday.

Are there shared practices for how folks structure their extensions? (My quick search has me feeling like it's the wild west right now)

yeah, i would say that's an accurate impression

the vscode sample extensions are good to get an example of specific features

otherwise, i would study architecture of well developed applications

eg. gitlens

Yeah, I've been reading through several. Good to know one you recommend.

Oh yeah, this is nicely structured.

hello, I have a qustion What dendron using for showing graph view??

@User we use a fork of the markdown-links extension https://dendron.so/notes/301e4129-6933-4be7-a4bd-8125171360d8.html

Whoa! https://marketplace.visualstudio.com/items?itemName=jakearl.search-editor-apply-changes

Sweet!

@User, after our conversation I did a quick check to see what I was thinking of when I mentioned Foam's backlink meta-data in document. They are using reference links (https://spec.commonmark.org/0.29/#reference-link), which allow one to define a link for a particular block. This doesn't make sense wrt our conversation about Frontmatter, but it DOES pose an interesting idea about Github's rendering of links. e.g.

[[this-wouldnt-normally-link]]

[this-wouldnt-normally-link]: this-wouldnt-normally-link.md

The second line is ignored by renderers. I wonder if these might be added by a build flag for those that want to "publish" to a github repo and have it be navigable there.

> Whoa! https://marketplace.visualstudio.com/items?itemName=jakearl.search-editor-apply-changes @User vscode reminds me of the app store - there's an extension for just about anything you want to do 😅

> extension for just about anything you want to do 😅 @User Seriously. Will be interesting to follow what direction they take.