Haskell-language-server: Documentation popup: \mathcal not resolved/formatted?

Created on 14 Jul 2020  路  7Comments  路  Source: haskell/haskell-language-server

VS Code with the current haskell-language-server master, GHC-8.10.1.

For some reason, when the Documentation popup is displayed - \mathcal{} content is not formatted. Here's what the popup shows:
Screen Shot 2020-07-14 at 11 29 56

Here's what I see after clicking on "Documentation":
Screen Shot 2020-07-14 at 10 59 32

Is it normal, or is there a way to make it formatted properly? How can I change my setup/configuration to enable that? Do I need to install some extra package...?

ghcide bug

Most helpful comment

Given this issue is fairly minor (visual glitch), and a consequence of upstream making poor decisions, I suspect it's going to be a while before anyone gets around to it. If you're particularly interested, feel free to investigate. For example, is it possible to enable JS in this context? Is JS enabled but the support .js file not found? Would it be feasible/desirable to rewrite mathcal before rendering it?

All 7 comments

The source text actually says mathcal, but then Javascript goes in and replaces it. In general, Javascript won't run on docs being served up from local disk (as its a security risk), which I suspect is what happens. I personally think that relying on Javascript to format a slightly slopey O instead of just doing italics is a dumb case of making everything worse so pedants can have a fractionally more correct O. In Hoogle I just drop the entire mathcal bit, since I'm splicing in snippets of HTML, and don't want some Javascript going on too, which trashes page reflow time etc. See https://github.com/ndmitchell/hoogle/issues/353

Javascript won't run on docs being served up from local disk (as its a security risk), which I suspect is what happens

As far as I'm concerned, the real security risk is a ton of crappy JavaScript pulled from all over the world that a lot of web sites link to.

I'd much prefer to have a configuration option to allow JavaScript run on docs served from the local disk, as it's an acceptable security risk (after all, I'm running this Cabal executable that came from the 'Net, ain't I? ;).

However, if it's possible to avoid JavaScript altogether - I'd love to embrace that solution. Is it feasible here?

It would be feasible for upstream not to use Javascript, if they wanted faster pages and an irrelevantly less precise font. But upstream seems to have introduced it deliberately and foolishly...

But since upstream is what it is - regardless whether their decision was smart or not, how can we fix it here downstream?

For example, I'd be perfectly happy with simply enabling Javascript to execute files stored on my local disk (I consider that risk far more acceptable than what web browsers do on almost each and every site nowadays).

Ping?

Ping?

Given this issue is fairly minor (visual glitch), and a consequence of upstream making poor decisions, I suspect it's going to be a while before anyone gets around to it. If you're particularly interested, feel free to investigate. For example, is it possible to enable JS in this context? Is JS enabled but the support .js file not found? Would it be feasible/desirable to rewrite mathcal before rendering it?

Was this page helpful?
0 / 5 - 0 ratings