miki

what Linux already has, and the filesystem. The reason for the simplicity motivation is that I've found, over the years, that the more complete a system I've used to try to "get organized," the sooner it will be abandoned. What I've devolved to is this: the "system" will be more usable, and more likely to be used, the less of that system there is. Of course it's loads of fun to write one of these things, and that's more than enough reason to do it, so go ahead! But you might keep simplicity in mind, start from an attitude of minimalism with just enough added on, and when it's good enough, stop. I guess all bets are off if you want an OSS project that other people are going to use and work on. In that case, "Release the Features!" :) However: > ... "designing the system so that the manual will be as short as possible minimizes learning effort." The above quoted in "Expert C Programming, Deep C Secrets," by Peter Van der Linden. I used my catalog to find it. :)

course, opening them from the browser directly also works.

my books in my wiki pages. The refactor problem is "solved" by "make badlinks", which prints out any bad internal links it finds. In your markup pages, you end your links in the markup suffix of the link's destination (if it's to an internal page). This way you can easily use your text editor's "go to file under cursor" feature to open the destination's source (who wants to open a pdf in Vim?); Miki transforms that into a .html, or .pdf or .txt suffix during output generation, as appropriate Coincidentally, yesterday I decided that it's "done enough," barring bugs or feature suggestions, and I recorded that observation in the Journal page in my local Miki-based wiki. That feels very slightly like a self-hosting compiler.