7/1/2023 0 Comments Youtube osx nvaltTherefore it is not robust but fragile to changes in the method. A wiki does not provide that flexibility. The ID and the title should be two separate things. This heuristic saved me from the problem Christian mentioned. Therefore, I do not use anything that could not be replicated with reasonable effort in plain text. On of the most important conditions for my decisions is robustness against change of software. The question could have been even more harsh because I even rejected the wikilink for a long time. Sascha found the nvALT-style wiki links to provide tremendous value and enhanced his workflow already by using them. I stick to my existing convention for the sake of consistence (and because I’m very stubborn and resistant to change) when I find out what’s next, I’ll migrate everything to the new convention. On the flip-side, this means the wiki links you write in nvALT won’t work when you import your archive into regular wiki software. That’s more useful for our purpose than the strict implementations of regular wiki software. That’s why ID-only wiki links in nvALT work well: you can append the note’s title in the file name and a wiki link will still produce the same result. Clicking ] in nvALT will match all notes containing “link target”, not just a note that’s exactly called thus. Wiki links are shortcuts to the search function. Instead your files will be called 201612111343.txt and similar, which is not useful on its own. …, but then you lose part of the value of plain text: being able to work with mere directory listings, that is being able to look at the file names in the archive and see what’s in there. Readability will not be harmed much because in most a wiki implementations you can add anchor text like so: So you will have to use IDs as page titles to get the same combo of flexibility (contents may change) and rigidity (link targets are stable). Titles may change over time as you extend, break up, or combine notes. If you argue that I need a script to create link definitions for my convention anyway, so I could just as well write an export script that translates double-square-bracket links to regular Markdown links, that’s alright, too.īut then you’d be missing part of the point: all your links will depend on the full title of the note. If you argue that the ] convention is wide-spread and mixing it with Markdown will not cause much harm, fair enough, you can have a Markdown-aware wiki software and get the best of both worlds. If you append that, Markdown preview Just Works.™ You don’t even need to extend the Markdown interpreter. It’s a simple translation of note ID to file path, and the note ID is part of the very path already. You could write a script that created a link definition for each Zettel note from the archive folder. The bottom part, where the Markdown links are defined, is missing in my notes. It’s easy to add a link definition, even manually, like this: As it is, this stuff isn’t clickable in any editor because a the link definition isn’t resolved anywhere. Historically, I went with the somewhat weird -convention to place the emphasis on utilizing existing Markdown implementation instead of introducing my own sub-format. So the question really is: if there is wiki software that read and write plain text notes to a folder on your hard drive, why not use that? There are native apps that use the WikiWord or ] convention to connect notes. Christian’s ResponseĭokuWiki requires a local web server (you can put it online, too, if you want access from anywhere), but this technological problem is not a real issue. Why did you choose nvALT, where you have to create manual links so that you can search and find which other notes ‘ backlinks’ to other notes, instead of a wiki (like DokuWiki, Tiddlywiki) where this would be provided automatically along with the benefit of plain-text writing/storage. Reader Question: Why Not Use a Plain-Text Wiki?
0 Comments
Leave a Reply. |