Automated back links about zetteldeft HOT 8 OPEN

Nice! That was quick. 😄

I guess it's clear to me now after reading a couple times, but at first it was not immediately clear whether or not this also creates a new node (or maybe I am just slow). The name of the function would seem to indicate that, although perhaps it would be better explicitly stated as a third (or perhaps best, first) bullet point?

from zetteldeft.

That could be nice indeed. I'm not planning to implement something like this at the moment, but if people have idea's on what this would look like (or want to propose an implemetation), feel free to discuss this here.

Personally, zetteldeft-search-current-id suffices.

Maybe, though, this is something we can achieve via an org-mode codeblock...

from zetteldeft.

I am still pretty new to all of this, still in the research phase. Nice project by the way, and thanks for sharing it. 🍻

I came here with this exact question on my mind in fact. 😄

If I am understanding correctly, such a feature would pretty much equal one of the key features of org-roam (2 way links) but without the need of a separate SQL database?

Although "two way links" would be a nice feature, I really don't like the idea of maintaining an SQL database in addition to my otherwise all text Org files, which would defeat one of the major features of Orgmode. Especially when I think it would be possible to implement such a thing whilst still keeping everything all text.

Or am I missing something here?

from zetteldeft.

would pretty much equal one of the key features of org-roam (2 way links) but without the need of a separate SQL database?

I have no experience with org-roam, but everything in Zetteldeft relies on plain text and Deft search.

The idea of making it all plain text is motivated by (1) keeping everything human readable (and solvable, at least to some extent), and (2) making it easy to replace the search back-end if needed (which is the Deft).

I’m open to ideas about what such a back linking system would look like, and how one would operate it. My elisp is not the most advanced, so PRs are welcome too

from zetteldeft.

I have no experience with org-roam

I don't either, just came across it in my research into this domain of software. I think it is at least heavily influenced by Zettelkasten method, if not a direct implementation. But I have never actually used it, either (and don't plan to if I can help it, as that SQL thing is a deal breaker).

The idea of making it all plain text [...]

You are preaching to the choir, brother! 😃

I’m open to ideas about what such a back linking system would look like, and how one would operate it.

I am too new to all of this to know anything yet, let me get my feet wet before I come spouting off any more ideas. 😄

My elisp is not the most advanced

I am only a low (to middle at best) level wizard myself, but you seem to be doing quite a fine job to me, especially for a (self described) "dilettante." 👍 🍻

from zetteldeft.

I've included a new function: zetteldeft-new-file-and-backlink, which can be used in an existing note to:

• create a new note
• insert a link to that new note in the original note
• insert a backlink to the original in the new note

Currently available in the develop branch in commit 21745f5.

from zetteldeft.

So, if I am understanding correctly, the new function zetteldeft-new-file-and-backlink handles the case of "I prefer to manually create back links on a case by case basis" and not the "let's generate all back links automatically", which is what OP was actually about.

To be honest, this is not a feature that I think I would personally even use. However if we implement this, suddenly we catapult ourselves into the big leagues (IMO) by getting on (at least one major) feature parity with org-roam, and all without requiring any SQL back end. Which I think would be pretty cool and worth doing. So thus follows my implementation idea. Please poke holes in it. 😄

I think the way to implement that would be to write some function that comes up with the list of links (or leverage existing function that does that already) and then call that via a hook, perhaps via some wrapper function that would check it the list already exists, and then iterate over / replace it or whatever.

Since hooks are really lists of function, whoever wanted this feature could add it to whatever hook we create by doing add-hook, and the people that don't want it (or prefer to do it manually) simply don't do that. Everyone is happy.

But I don't think any of that is the "difficult" part of implementing something like this. How would we want to format this list, in order to make it easy to find and work with?

I think we make some (configurable) variable containing some string like "What links here?" and then insert that at the end of the buffer (after a newline), followed by the list of links. We specify that this always needs to be at the bottom of the page / file. Which actually makes a pretty easy implementation (just start at end of buffer and search backwards for string), as well as keeping this metadata at the bottom of the file (out of the way) which I think is a good place for it.

Discuss! 😄

from zetteldeft.

the new function zetteldeft-new-file-and-backlink handles the case of "I prefer to manually create back links on a case by case basis" and not the "let's generate all back links automatically", which is what OP was actually about.

Yes indeed, the idea is to make those backlinks manually. Writing something that does this automatically (i.e., always list all links to the note in question and keep that list updated) would require notes to be structured in a very specific way. This runs counter to the idea of an open and plain. text notebook, imo.

That said, if someone wrote a function to do precisely this, I'd be happy to consider including it, depending on how much complexity and rigidity it adds to note structure.

For those occasions where one wonders "What links here?", as you put it, there is zetteldeft-search-current-id, which launches a Deft search with the ID of the current note.

Come to think of it, this could be semi-automated with a codeblock. I've added a note to the zd-tutorial knowledge base: https://github.com/EFLS/zd-tutorial/blob/master/2020-08-29-1223%20List%20of%20backlinks.org

I think this comes very close to what is asked here, as executing the source block takes care of it. Updating that block could perhaps be automated via a hook or something similar.

from zetteldeft.