support for "atomic" nodes only?

[akashpal-21]

Hello, I tried out this package, at first I had to spend a few hours to get my head around it, but I then realised its not for people who keep multiple nodes in one file since adding to desktop a node pulls all the nodes in the file, even adding to the scratch yanks the entire file... this makes it no different than going in ones emacs scratch buffer doing M-x org-mode and manually yanking the entire file by M-x h M-w > then C-y.

Am I missing something or is adding individual nodes impossible in this setup?

[Vidianos-Giannitsis]

Hello. You are correct, there is currently no support for what you are asking for. I am currently not aware of how to fix this and it would probably require a fairly significant change to the package backend (read on for why that is) although I believe it should be possible. I currently do not have the time to devote to it however, so no promises for when and if this will be fixed. I will try to look at it during the holidays, if I have the time.

Now for why this is hard. Zetteldesk, under the hood works with buffers (essentially, the concept is that the filtering works via changing the value of a buffer local variable in the buffer associated with the thing you are adding). This felt like a sensible choice when I first made the package because it was one of the easiest to implement (and my coding knowledge, especially at the start of this, was not great) and allowed me to very easily use various formats and not only limit it to Org-roam (which for me matters as I sometimes also want to include supplementary information in the zetteldesk).

Org-roam behaved as I expected it to because I am a big fan of the one file per note approach, so for me, each node is uniquely associated with a buffer. However, this concept completely breaks the package in the case where the node to buffer association is not 1:1. For this reason, supporting this would probably require completely changing the backend, from checking a buffer local variable, to something that can work on a node basis. This also means that that technique is 99% not going to be compatible with other file formats (except if I figure out something very smart for that) meaning that Org-roam nodes would need to be almost disjointed from the rest of the package and albeit org roam being a focus of mine, it's not the only thing I use.

So having explained the complexities, I cannot promise to get this fixed, due to time constraints, although I do believe that it is noteworthy to fix. However, I'll definitely give it a more in-depth look and try to fix it.

Thanks for your interest in the package and sorry for the inconvenience.

On Mon, Dec 4, 2023, 1:16 PM Akash @.***> wrote:

Hello, I tried out this package, at first I had to spend a few hours to get my head around it, but I then I realised its not for people who keep multiple nodes in one file since adding to desktop a node pulls all the nodes in the file, even adding to the scratch yanks the entire file... this makes it no different than going in ones emacs scratch buffer doing M-x org-mode and manually yanking the entire file by M-x h M-w > then C-y.

Am I missing something or is adding individual nodes impossible in this setup?

— Reply to this email directly, view it on GitHub https://github.com/Vidianos-Giannitsis/zetteldesk.el/issues/13, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGY5W727DCB3K5STUG6SALYHWWIDAVCNFSM6AAAAABAFZQPPWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDGNRRGM4DQMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[akashpal-21]

Thank you for such a detailed response. I understand your thought process. I would like to say a few words here, Org-roam v2 is distinctive because it allows for keeping nodes utilizing a database framework where nodes are simply a header with an associated unique ID. In the old days when there were no digital medium to keep notes, the zettelkasten method was devised and the slip box mechanism is really a because of a technological hurdle, the paradigm of keeping small cards and each card being a separate entity in itself makes sense in an analog world. Utilising this mechanism in the digital framework means littering one's folders without much benefit, in fact it is a pain to maintain so many small notes which requires constant oversight so that duplication doesn't occur. There are many other frameworks to keep notes and they all ask of the user to keep atomic notes not because it is a benefit in itself but because of a technological hurdle off not utilising a database framework, in fact we do not need org-roam to implement such a system, we may do all this just keeping .md files and linking them we may also use a few bash script to make this into a process of some sort.

The Readme could be much simplified, once I got my head around the fact that the zettledesk is a parallel space that stores the files added - everything fell into space. Much complaints regarding the difficulty could be avoided in an one liner stating the difference between the zetteldesk and the zettelscratch, much of the learning curve involves here only. Also there are many #'functions but none to see what files were added to the zettledesk - which only exposes itself when adding to the scratch of removing them! So I think there is space for improvement here, mainly to simplify the whole process.

The current state of the application could be forked into its own thing which maintains compatibility with other applications and processes while a separate framework written from scratch could only be written for org-roam, because org-roam is unique and very powerful and a thing in itself allowing itself to adapt to both the use case where the user may want to keep "atomic notes" or nodes inside of files for better organisation and house keeping.

I understand that you are busy and such a thing may be in a far future, but if such could be done, I think it would greatly help in review and writing documents utilizing the notes one has created, this tool would then live up-to it's original intended goal. This tool is very unique and has the potential to be the de-facto org-roam review tool.

Best,