Basically I wonder if it would be possible to allow the user to define their own text information box like the ones for tags and ids.
The reason for that is that I would like to be able to use it for folgezettel.
I got inspired by this thread https://twitter.com/AGWilsonn/status/1156604889491005440
I would still use the ZK as recommended by ZKM and use timestamps for ids and to link to notes, and create structure notes normally, etc.
However I can create a folgezettel by for example putting FGZ: somewhere in the file (I put it at the beginning of one of the first lines below title) then after that I can put the folgezettel id, so I can end up with FGZ:1a1b or FGZ:ZMM5a7b or whatever you want.
This approach has the advantage that unlike Luhmann's it is more flexible because it is not the main way of identifying a note, which means I can change those ids if I want to (as proposed in the twitter thread), without breaking anything and you are not limited to your previous assumptions.
And you can do crazier things like creating chains of multiple folgezettels like: GRBL01a02b=GRBL11b
I can search for these folgezettels through search, but as it is currently I would have to manually look at every file, plus the ids themselves are not sorted, this can be partially remedied by being more specific in the search but it is not the most convenient way.
So I am wondering if it is practical and doesn't affect the performance of the app too much to allow to define a text info box so that what I put behind it will be displayed in a text info box like ids or tags. So that if I define it as FGZ: whatever I put directly after it will be displayed in that text info box.
So if write FGZ:1a5c27, or FGZ:GRBL01a02b=GRBL11b or FGZ:ZMM69x420 it will display the 1a5c27, GRBL01a02b=GRBL11b or ZMM69x420 in that box.
Additionally if it is possbile it would be neat if we could sort alphabetically based on those boxes. This could also be applied for timestamp ids to allow proper sorting when they are not in the filename.
Ugh, I'm not sure I want to/can do this
Ugh, I'm not sure I want to/can do this
I see. Its not a big deal if implementing it would be too difficult.
In case there are any resources available in the future, we may re-tackle this ;)
In case there are any resources available in the future, we may re-tackle this ;)
Nice. But like I said this is by no means a necessity, this is more asking for feasability of it. If it would detract from other things there is no need for it. So no need to hurry.
Btw I just thought maybe you could "misuse" the custom TODO, once this has been implemented, to achieve the same. This way we could try to cover two different applications at once and save some time: #192
Btw I just thought maybe you could "misuse" the custom TODO, once this has been implemented, to achieve the same. This way we could try to cover two different applications at once and save some time: #192
This does look pretty good if it works as good as I think it will. It could be even better than what I originally envisioned.
Most helpful comment
Btw I just thought maybe you could "misuse" the custom TODO, once this has been implemented, to achieve the same. This way we could try to cover two different applications at once and save some time: #192