JupyterLab Markdown and Raw Cell Error thrown by LSP

[saffaalvi]

When a new markdown or raw cell are added to a Jupyter notebook, an error repeatedly pops up every time you try to interact with the cell:

After some testing, we have found that this error is coming from LSP and happens to be caught by another extension (Kale) as mentioned in kubeflow-kale/kale#165. The dialog with the error message is then displayed by the Kale handler.

When only one of the extensions, LSP or Kale, is enabled (not both), the error is resolved.

Not sure why LSP is throwing this error and how to resolve it?

[krassowski]

You are correct this is an issue at our end. It does not break anything and is difficult to narrow down (async/concurrency) but I will try to eliminate it in the next release.

Sorry about it!

That said, the other extension should probably try to catch their own errors only... Not sure if we can help with this.

[bollwyvl]

Thanks for the report! We (and it looks like kale) should really get to a zero-output-unless-somethings-really-broken state. We could add a URL hack, e.g. #JLSP_DEBUG, and a startup message documenting it, and hide everything else, but 10k lines of console, no matter how you filter it, is no good for anybody.

extension should probably try to catch their own errors only

Hm, that might be a lab-level dialog, but indeed, very hard to tell.

Having a binder that demonstrated the condition might be about the best we can do: unfortunately, what's probably not going to happen is us ginning up a test in our suite with kale installed, as we've got enough trouble running against core x operating systems x python versions, and maybe something like ipywidgets.

[bollwyvl]

The sad thing is we don't even handle markdown cells yet 😿... we'll get there.

[ca-scribner]

If it helps any, we noticed this by installing kale onto a notebook server that (we thought) was running without any errors, and suddenly we'd see these notices. At first we thought it was Kale, but someone on the kale issue noticed that kale was finding uncaught errors that happened to originate outside kale. So for testing I'd guess you don't need kale in your test suite but instead something looking for uncaught errors might do?

Full disclosure, I know nothing about this topic :) Also - thanks for the quick responses and the lovely lab extension. If I am stuck having to disable this extension whenever I want to run kale I will, but it'll be like choosing between my children.

[bollwyvl]

Welp, messing with mouse event handlers on DOM we don't own is bad, jquery-style business, and neither of us should be doing it... but we gotta. I have a personal vendetta against dialogs, anyway, but it seems like like a UI device that should never be a planned result of moving the mouse, no matter how bad the error is.

Recent labs (2.1.x+1, where i don't remember x) have a log view capability, but it's very limited at present in terms of who can write to it... we really should be writing to something like that.

[sylus]

Would it be possible to get a pre-release to test this functionality out? :D

[krassowski]

I'm gonna do the point release tonight :)

…

On Wed, 5 Aug 2020 at 14:48, William H ***@***.***> wrote: Would it be possible to get a pre-release to test this functionality out? :D — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/krassowski/jupyterlab-lsp/issues/299#issuecomment-669204285>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMQBRSBYDARA3GYUM632TTR7FPMLANCNFSM4PJCTP3Q> .

-- Best regards, Michał Krassowski

[krassowski]

It's done. Please let us know if the fixes helped!

[sylus]

@krassowski will do thank you so much :D

[sylus]

Confirmed that this fixes our problem :D

Thanks so much!

[bollwyvl]

Thanks for getting back to us. Happy for any further feedback on your use cases and experiences using the extension(s)!