Add texlab for LaTeX

[bollwyvl]

References

• for May you show how to create a Latex spec file? #287
  • let's keep that open until we ship the changes in this PR, as it's not a simple drop-in, and even once it is, we'll probably have more issues with this server than others (ha!)

Code changes

• add texlab to test/demo environment
  • also tectonic
  • also chktex
• add texlab spec
  • add to setup.cfg
  • add to unit tests
• add to docs
  • i've put it under a new section...
    • i think we need to make this one as good as we can, but there will be rough edges for now, like completion
• fix sending null instead of {} for initializedParams
  • unsurprisingly, rust is really hard core about types 🤣
• add robot tests
  • editor
    • rename
    • jump
    • diagnostic
      • it's sending back messages, but they're always empty... need to investigate
      • chktex is the engine of choice referenced in the documentation... apparently there are some inconsistencies in the one that comes with different platform distributions.

      investigating the feasibility of building/packaging this

  • config
    • by default, it uses latexmk which is hard to ensure under test. a config test of using tectonic would be cool
• figure out how to get RTD to pick up new spec

Not Appearing on this issue

• hover
  • we don't have any hover tests! 😭 Add Robot Tests for hover #297
• transclusions?
  • %%latex isn't working just yet, %%latex doesn't show diagnostics #296
• custom commands?
  • i feared this day, when a language server would provide a custom message i really want to try (namely, build and forward search)
  • i kinda don't want to do it yet [wip] Add Language Server Proxy Kernel #278

User-facing changes

• Can now view get some feedback on .tex files 🎉

Backwards-incompatible changes

• None

Chores

• linted
• tested
• documented
• changelog entry

[bollwyvl]

Ha! Thanks for the approval, but still cooking on this one.

I have hit some walls getting chktex to build... I feel like I, personally, would really benefit from having the linter, so I'm going to keep churning on that, hopefully have something to show soon

[bollwyvl]

I did get chktex built, so will be able to push forward with this, soon. If nothing else, it will find if my potentially-wonky OSX builds actually work.

[bollwyvl]

it's looking good:

[bollwyvl]

One issue, though, is that the diagnostics don't show up on save... and apparently should by default. Will add a test that enables them, i guess.

[krassowski]

Re-diagnostics - they work in a new notebook:

[krassowski]

They even work after copy-pasting all cells to the new notebook:

But markdown stopped working for me here...

[krassowski]

It works even after closing the notebook and opening it again. It consistently does not work in the Foreign extractors.ipynb notebook. Could it have to do with the space in the file name?

[krassowski]

It seems that it does. Renaming Untilted.ipynb → Until ted.ipynb broke them. This is good to know and we should test it - it is likely that users will have filenames with spaces.

[krassowski]

Is this conda-only or is there a reasonable (maybe not single command I guess) alternative for let's say Ubuntu users?

[bollwyvl]

latex installation, care, and feeding, is one of my personal circles of support hell. for example, because i run a small root partition, i can't even use the "easy" route on my machine, unless i handpick all of the stuff it would need to work, because i would run out of disk space.

with this, like nodejs, or anything else in the stack, providing inaccurate install docs is worse than nothing, so i think the best thing we can do is:

• provide a link to the various official install docs
• show an example of what we know works, because keeping it working is on the critical path to us merging adding/changing feature.

the only way i'd be interested in documenting or supporting n distros, would be if we had additional Dockerfiles we ran the full battery of tests against with the release tarballs... and that seems like an awful lot for this

That being said, it looks like the docs aren't pick up the new spec:

https://jupyterlab-lsp--288.org.readthedocs.build/en/288/Language%20Servers.html#Other-Scientific-Languages

[krassowski]

About the docs - R does not show up on the PR builds too, but it is ok on master; would it have to do with your changes, or is it a limitation of the PR builds?

[krassowski]

Well, my personal standpoint is that having a Debian/Ubuntu install is usually good enough. Not only because it is a common one, but also because I can always google "how to install X ubuntu package equivalent on Y" and it more often works than it doesn't (unless speaking of exotic distros). This trick also works for Y=Mac (sometimes).

But I think this is not holding this PR from being merged - let's just make sure we show links to official docs of the tools we require to make latex work!

[bollwyvl]

I guess let's see how the docs build goes... I didn't have to do anything too fancy to the specs.

Debian/Ubuntu install is usually good enough

I suppose... but again, I've never tried to do one... it's definitely one of those things I Docker-and-forget in a build toolchahin. Indeed let's hope that the texlab docs link is sufficient.

[krassowski]

and we should test it

come to think of it, this is why Foreign extractors.ipynb has space in the name in the first place. I think we discussed this earlier - good job past us.

[bollwyvl]

Excellent catch on the spaces. Of course that would break something in a stack this weird. Everything can go wrong once humans who, you know, use computers to get work done, start getting to make choices! Sigh.

I know there are some file path normalization things that changed in 2.2.0, and we likely have some more places where bad stuff happens. I'll do a little more looking later today...

[bollwyvl]

So in handleDiagnostic, the response coming back is not URL-escaped, while our internal reference in document_info is.

I guess we need to figure The One Way we are going to standardize these... I can start looking on this pr, or we can handle it on a separate issue. The worst way, we'll want a util.isSameUri. The better way would be to use the upstream https://github.com/microsoft/vscode-uri which has no dependencies (:tada:) and is probably what enables all this inconsistent wire behavior to actually work in The Client.

[krassowski]

Great find, thank you! I think, it's best to address it here so we can have test in. I would be happy with either of the two (an util or the vscode-uri way)!

[bollwyvl]

I tried out vscode-uri, and one of the first things it did was error out with a max recursion depth issue. yeesh. have rolled that back, and will start over. we do already have a util for checking uri equivalence, i guess the right play will be to use that more, and make it more robust to weirdness as we observe it.

[bollwyvl]

the OSX fail looks spurious, checking out the win fails on my vm...

[bollwyvl]

Actually, one must indeed still add the config to get onChange or onSave diagnostics.

…

[bollwyvl]

Back to green, no further changes intended, and might even be out of the loop for a couple days (wifi-depending).

[bollwyvl]

Hooray!

Also shows up fine on the docs.