121
General Software Discussion / Re: I'm thinking of going primitive, with discursion into zettelkasten
« on: August 14, 2020, 02:58 AM »
You are together building the case for Obsidian for my particular use style and needs :up:
One other strong consideration for me is that local plaintext files are very much easier to do stuff with from small AutoHotkey scripts for superspecific processing tasks, quick tweaks and more.
I hope that the Block Reference feature request discussed in their forum comes through. Specifically these thoughts are much in line with my brainstormed wishes for transclusion earlier here on DC. Such atomicity seems like a must have feature to me. But a challenge for Obsidian devs: how to implement that while staying with (1) plaintext files and (2) openness in the sense of plaintext files still being editable in other tools without a big clutter of long UID strings everywhere?
If (1) was the only requirement then the three level approach seems pretty straightforward: raw view, transclude view (resolve transcluded content, resolve UID strings as small icons, dots, color styling or some such) and preview view (fully resolved). Those who use transclude features would then spend most of their time writing in the mid-tier transclude view in Obsidian, but sometimes jump to raw view to fix issues. Obsidian and plug-ins would operate on the raw view data in the background.
But I can't think of a way to get convenient, reliable transclude atomicity in a set of every changing plaintext files without a paying a price re (2). Seems like something has to give. Bet: transclusion will prove so useful that Markdown syntax will be extended for it. Hopefully in a standardized way. NetCommonMark (Net as in networked notes) on the horizon? Once standardized other note apps would have similar transclude views so there would be less of an lock-in effect to the Obsidian editor.
One other strong consideration for me is that local plaintext files are very much easier to do stuff with from small AutoHotkey scripts for superspecific processing tasks, quick tweaks and more.
I hope that the Block Reference feature request discussed in their forum comes through. Specifically these thoughts are much in line with my brainstormed wishes for transclusion earlier here on DC. Such atomicity seems like a must have feature to me. But a challenge for Obsidian devs: how to implement that while staying with (1) plaintext files and (2) openness in the sense of plaintext files still being editable in other tools without a big clutter of long UID strings everywhere?
If (1) was the only requirement then the three level approach seems pretty straightforward: raw view, transclude view (resolve transcluded content, resolve UID strings as small icons, dots, color styling or some such) and preview view (fully resolved). Those who use transclude features would then spend most of their time writing in the mid-tier transclude view in Obsidian, but sometimes jump to raw view to fix issues. Obsidian and plug-ins would operate on the raw view data in the background.
But I can't think of a way to get convenient, reliable transclude atomicity in a set of every changing plaintext files without a paying a price re (2). Seems like something has to give. Bet: transclusion will prove so useful that Markdown syntax will be extended for it. Hopefully in a standardized way. NetCommonMark (Net as in networked notes) on the horizon? Once standardized other note apps would have similar transclude views so there would be less of an lock-in effect to the Obsidian editor.