Markdown in `@description()` decorators

[Bzero]

469 added the option to use (some) markdown in @description() decorators which I think is very neat for the online documentation and helps to make it more readable, however it also makes the description a bit inconvenient to read in the cli using the info command.

Possibly we could directly use Unicode characters instead of LaTeX commands in formulas (e.g. $Γ(x)$ instead of $\Gamma(x)$) and use colors to highlight code and math blocks to make descriptions more easily readable in the cli.

[sharkdp]

I only thought about improving the online documentation but forgot about info for a second there, sorry about that.

I know that there are some markdown viewers for the terminal. Maybe the easiest way forward would be to use one of these (as a library)? For example, they might be able to show markdown links using ANSI hyperlinks? The problem is that they would need to support Latex formulas as well, but maybe there are some?

Possibly we could directly use Unicode characters instead of LaTeX commands in formulas (e.g. $Γ(x)$ instead of $\Gamma(x)$)

If nothing else, we should definitely do that... if it will still be recognized by mdbook and its mathjax support.

and use colors to highlight code and math blocks to make descriptions more easily readable in the cli

If we don't get this from an external library, we could certainly attempt to do that. But I'm yet not sure if I want a custom markdown parser just for that(?).

[Bzero]

Maybe the easiest way forward would be to use one of these (as a library)?

Yes, if there is a library that can display markdown including math blocks in the terminal this would certainly be the easiest and probably also best way. I had a brief look around but could unfortunately not find a terminal markdown viewer library that can display LaTeX formulas in a satisfactory way.

But I'm yet not sure if I want a custom markdown parser just for that(?).

No, I wouldn't suggest that either, however I think math and code blocks are the most important markdown features for the use case in numbat and detecting those should not be too hard.

[sharkdp]

Another option would be to have two fields (@doc and @info or similar). But the duplication would be a real shame. On the other hand, we would only have to do that for the functions with formulas in the descriptions. For the others, one of them could fall back to the other.

The LaTeX we're using so far is extremely basic. Maybe we can indeed write a small parser ourselves? And turns things like \sqrt{…} into sqrt; \frac{…}{…} => (…)/(…). And for symbols like \pi and \Gamma, we could check if it's possible to use unicode characters.