Interesting, when I saw the headline, I immediately thought it was something else that I want: I keep all of my notes as plain-text Markdown files, and I use Wiki-style links between them, like `[Another File](another-file.md)`. One of the pitfalls of this approach is that if you change a filename, then all the links referencing that file will then be broken. So I'd love a tool like this that can be used to clean up a directory full of these documents.
Love to hear any more commentary about the pros and cons of this approach? I assume the main reasoning is that it’s easier to make a link?
The nice thing about the `[File](file.md)` method is that it’s markdown native, e.g., you can follow them in GitHub, if you have a way to render file URLs HTML, you’re links will just work in the browser too, and many txt editors can follow them by default.
The only time I would use the `[File](file.md)` syntax is if I'm specifically making documentation that will be published for other people.
Also, Github uses Gollum, which actually supports wiki style links anyway.
If you are maintaining a knowledge base, it gets really tedious to do that, if 99% of your links are just going to have the same caption as your filename. So being able to make links as quickly as possible facilitates efficiency. Besides, there are alternative syntaxes for being able to specific a custom caption for a wiki-style link.
Another thing to consider, is that in most mediums that I use my knowledge bases in, they are not styling my links anyway. I can still of course follow them automatically, but they are just presenting them as [[Links]]. Most people prefer that.
My different wikis have gone through many different iterations, and most of these engines are fairly compatible-ish with each other. They are similar enough that any migration required could be done with a few lines of Perl on my set of md files.
Huh, ok I just tried this out and it doesn't work as well as I was hoping. It appears that that `[[A file]]` style works on GitHub Wikis but doesn't work in the repo browser itself (e.g., from the `README.md`)? That's a major limitation to me, because one of the big benefits of my approach is I get a free web version of every local Wiki that I have on GitHub.
I'm curious if you have another solution for actually publishing a `git` repo on the web using the `[[a file]]` link style?
The name is a pun on "broke"? (I first thought it was Swedish for "brøk" (fraction/ratio), but it turns out Swedes don't say "brök" but "bråk", which just means "noise" in Norwegian&Danish. But that's way too convoluted a pun, even for Haskell).
This is cool although for practical purposes, I think most people who need such a tool will not be using Haskell. It is tempting me to add Haskell to my CI just because it looks so nice and easy to use.
Pardon my ignorance about compilers, Haskell, and programming in general (I have no background in CS, please don't roast me :), but cannot the Glasgow Haskell Compiler (GHC) produce a (binary executable) package that could run in Linux/Windows without having Haskell?
GHC is notoriously large. The compiler itself is around 1.5GB (this includes documentation, static and dynamic libraries).
To get an idea of the size of the bare-minimum system that's required to develop in language x, you can look at the cumulative sizes of the Nix package closures. This is what I get for ghc, nodejs and python3:
That seems to be a packaging issue with MacPorts. It looks like it's including build dependencies, too. It's pulling TeX Live and the Sphinx Python bindings for formatting documentation. I'm not sure what Perl is for, or why it needs 3 different versions of Python.
The Debian package doesn't require any of those. The Homebrew package has no dependencies at all (and only "python" and "sphinx-doc" as build dependencies).
On Arch Pandoc “only” requires a few dozen or so Haskell packages. Installing it does kind of mess up pacman’s output when updating etc, but that’s a very minor annoyance for a pretty useful tool to me.
