Open benknoble opened 4 years ago
Design thoughts:
Compiling the wiki (and thus running the tool) would probably be faster if I didn't have to find all possible links and create them (fortunately, <a>
works in <pre>
). This would probably require a custom JS mouse-click handler to try to find the documents, along with an index of documents—ultimately, I think this creates a poor user experience in the name of making it easier for the tool author (me). Someone smart once told me that we, as authors of code, should do the hard work so someone else doesn't have to.
To that end, I would much prefer a design that creates proper links and well-formed HTML—it is more accessible, more standard, and less surprising. I would consider a trade-off in ease of development acceptable towards this goal; moreover, I would be willing to sacrifice some portion of a performance goal in service of a better user experience, though generation speed is still a priority.
I think I could write a program to turn the wiki into a HTML site or something similar. Markdown processing is easy, and source-code can be wrapped in
pre
s.Challenges:
gf
--the right ones need to be resolved to documents and turned into hyperlinks in addition to standard markdown links[]()
and[][]
<pre>
with links as a POC? One other option is to include a config that maps "file patterns" to "processors," such as*.md -> md2html
,static/* -> noproc
, or*.my-ft -> shell('my command')
... Alternately, perhaps I could take the filetype mechanism code from ripgrep, and only support processing markdown to HTML as a PoC? Not processing certain files is still an issue, so said filetype mechanism may need adapting into the "processors" as before.Goals:
Extensions:
Non-goals: