Graph backend for notes (-> zettlekasten)

[rambip]

Graph backend for notes (-> zettlekasten)

[shaunsingh]

Agreed, super fun to work with. I believe coq.nvim uses it too if you need an example to work off of

[vhyrro]

Of course there are plans for that :). Neorg will have it baked in (it won't be a separate plugin like org-roam is for emacs's org-mode). I'm also a huge fan of the zettelkasten way of doing things and being able to build a network of nodes together. I also know there's a GTD crowd awaiting their feature set too! I want to get 0.1 out of the way first, is that alright? It shouldn't last long before it gets released to everyone (the most painful part will be writing the docs for it). 0.2 will be the "workflow update" where we get a table editor, GTD, zettelkasten, potential calcurse integration, agenda etc.

I'm considering using a real database for the backend too (that's what org-roam v2 does). I'm open to ideas in that regard.

[vhyrro]

The thing is that neuron.nvim uses the physical neuron binary. Neorg doesn't want to rely on third-party binaries to be present on the system. At the same time I guess there's nothing stopping someone from making a Neorg module that will be able to make migration from the neuron binary easier, right?

I know that rewriting already existing things is not great, but I fail to see an easier option. Neuron uses markdown for its notes which simply doesn't play well with a whole other format like Neorg's format, or at least that's what I'd think.

[rambip]

That project really seems amazing !
What you could also do is colaborate with the guys from neuron, or at least seeing what ideas they have.
It would be a waste of ressources if your 2 projects end up doing basically the same thing; maybe they could play well together ?

One interesting feature of neuron is that they can sync your files pretty easily, I don't know if this is specific to markdown. Definitively check their ideas out, that seems to be a solid concept.

[rambip]

Yeah I totally understand it's hard to crate a unified experience from fragmented software.

What we need is a way of storing .norg files names that is not dependant on the filesystem. But maybe a full database is overkill ?
I don't know exactly why they decided to use a full database for org roam ...

You should find a way to list .norg files in a per-project way, so that each .norg file has a "category" and each category has an index with list of files that are part od that "category".

The difficulty is to make that independent from the filesystem: If I have a single .norg file, I want to be able to link it to another file in a particular category, regardless of where it is on the system.
But I probably want a folder where I put every notes on a particular subject ...

I'm thinking of a way it could work (at least for me):
Create a file like .norg_index in your home directory. Use a readable syntax like yaml maybe ?
Add subjects (or categories I don't know how to call them) with mounting points on the system, ie a map from subject names to paths.
For each path, create a folder filled with .norg files, wiki-style.
So for every .norg file in a folder full of other .norg files, creating a link should be easy.
And you could link to another category, using your userwide .norg_index (like [[languages:rust]])

I have no idea if that idea is helpfull to you, at least that could work pretty well for me (and no need for a database 😉 )

You could also create helping functions like "create category", "add and link file" and so on

[vhyrro]

Sounds interesting. Being able to access .norg files from across different workspaces sounds great. I don't think that storing a global file would be the most efficient solution since you should only really be working within workspaces themselves (which you explicitly list to core.norg.dirman). I'm pretty sure they chose to use a database for speed (as lookup in a database in a lot lot faster). We'll see how we roll hah, if I manage to create a solution that is efficient and doesn't require a fully fledged compiled database then we won't use it, simple as that :)

Also regarding the helper functions I'll be certain to implement those when I get around to it. Since I use Neorg myself I tend to catch little things that I'd like to be able to do and implement them.

[rambip]

The point of using a user-wide list of workspaces is that you can create an helper function that creates one automatically (and I think the database had kind of the same role ?). How would you do it orherwise ?

[rambip]

And for efficiency, you could ls every path monted in this global file at startup and create a trie data-structure with it. I think listing directories can be done in a reasonable time, and indexing a trie is really fast (the complexity grows with the length of the file name, not the number of files)

I will try to implement my idea, and if it is succesfull, maybe this will be my first PR 😃 !

[shaunsingh]

On the database side of things, maybe sqlite.nvim would be of interest? I believe org-roamv2 uses sqlite as well

[MordechaiHadad]

On the database side of things, maybe sqlite.nvim would be of interest? I believe org-roamv2 uses sqlite as well

@vhyrro use SQLite it's super good local db and based too

[vhyrro]

In order to keep everything in one place I'll close this issue and recommend checking out the tracking issue instead!