Add support for VSCode plot pane display.

[korsbo]

This PR would allow for a no-additional-dependencies way of getting LaTeXStrings rendered in the VSCode plot pane - if that is something you'd want to support.

I get that you are not interested in supporting rendering through lots of external dependencies (#43) and I agree with that. This suggestion is quite a bit lighter than that though - enable HTML display and prepend mathjax import to the string.

I submitted a PR rather than an issue since that more clearly demonstrates what I had in mind. I'm overloading Base.repr because VSCodeServer.jl seems to ignore the Base.show overload that I started with. If you decide that this VSCode rendering functionality is worth having and that overloading Base.repr is strange, then I could have a chat with the VSCode people to see whether we should fix things such that LaTeXStrings.jl could overload show instead.

Anyways, it works as it is now if you want to check it out.

Cheers!

[stevengj]

I don't understand why overloading Base.show(io::IO, ::MIME"juliavscode/html", s::LaTeXString) wouldn't work — that is called by the repr(::MIME, x) that is called by vscode. Are you sure?

@davidanthoff and @pfitzseb, how do you feel about LaTeXStrings using MathJax for display like this? (What do you do for rendering equations in Julia Markdown?)

[korsbo]

I have not yet figured out why but

function Base.show(io::IO, ::MIME"juliavscode/html", s::LaTeXString)
    print(io, "hello")
end

Does not do what I think it should. It enables the mime and ensures that the plot pane is used but it ignores the function body and prints the latexstring rather than my friendly greeting.

I have other overloads of Base.show(io::IO, ::MIME"juliavscode/html", ...) that work just fine so this one was a bit of a headache. I figured that I'd check with you whether the main idea of mathjax + html rendering was inside the scope of what you want LaTeXStrings.jl to do before I dug deeper.

[davidanthoff]

I have so far always thought of the plot pane in VS Code as being for plots specifically, and nothing else, in particular not as a generic rich display. Not sure whether that really makes sense, but that has been the philosophy so far. So right now we only show MIME types that we think fall into the plot category, namely these. Markdown for example is not part of that list.

We do display help markdown in the extension and use katex for the math in that, but that is completely distinct from the Base.display architecture.

We try pretty hard to make as much stuff work in offline scenarios in the extension, and the way this PR here is implemented would presumably only work online, because it doesn't ship mathjax, but downloads it from the web. I think with the current architecture we have there is no way to handle this differently, though, for stuff that comes in via our own MIME type...

I definitely think this should work with Base.show, rather than Base.repr. I think we are doing nothing weird or fancy in how we hook into the display system.

So I think from my end the biggest question is whether it is a good UI experience when equations show up in a plot pane... We could also think about another possibility: right now the extension displays MIME types that we categorize as "plots" right away in the plot pane. But for tabular sources we don't hook into the display system by default, instead we provide an option that one can do df |> vscodedisplay and only then does it open a new tabular data viewer. That viewer is not part of the plot pane, it is just a standalone document in the editor. I could also see a scenario where we add another MIME type a la juliavscode/html-standalone or something like that which would behave in that way. That would enable a rich display that is not part of the plot pane and is also not hooked in by default. We could even just enable that for standard markdown or latex MIME types, I guess...

[korsbo]

I think it would be a good UI experience to have the equations rendered somewhere but I'm not wedded to the plot pane. Latexify already has a function render similar to what you describe where L"\frac{x}{y}" |> render displays the equation in the plot pane. The only thing that this PR would add to that is that the display would happen automatically.

I had not thought about the offline problem and I agree that having the call to render/display or whatever we'd like to call it might be a solution, albeit a somewhat unsatisfying one. In such case it might make sense to place this functionality in a LatexRender.jl package so that the same render function could have methods for more than just VSCode. I already have some of that functionality in Latexify.jl but if we decide that auto-rendering is not a good option for now then I think this functionality would be better placed in a separate package. Alternatively, we could just be ok with the way that it "renders" offline. It will just be displayed as plain text inside the plot pane. Less natural than having it in the REPL, but not a big regression from the current state.

Having infrastructure for better rich display support would be nice overall. Displaying markdown and general HTML would be nice! Is there anything keeping us from going all out and adding CSS and javascript support too - allowing for reactive applications? I don't quite see why such a mode of display would be separate from what's currently the plot pane though. Dispatching different display types to different window panes seems a little bit odd to me. I think that the natural classification for determining which pane to use is not from the type of object but rather in the mode of user interaction (documentation lookup, variable inspection, rich display, REPL, file navigation, etc.). With that frame of mind, I make out little difference between a plot and a rendered HTML page (which might include plots).

So, I see three paths:

1. Evolve what is now the plot pane to a rich display pane (over time). Let this PR be a step in that process - just figure out how to make Base.show overloads work (I know it should work but it does not when I implement it for LaTeXStrings).
2. Make a new rich display option in VSCode and let latex be rendered there. We could then close this PR and leave the specific latex support until the general framework for rich display is in place.
3. Don't let rendering be automatic at all - make a new package that aims to render LaTeXStrings as naturally as possible in whatever environment the user is coding. Which VSCode pane to render in would then be up to that package. I'd start with the plot pane until such time that any future rich display pane is in place. Needless to say, this PR should then be closed.

I have a slight preference for 1. but I'm open to any of these options.