You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have followed fully the installation steps laid out in the documentation site.
I have restarted jupyterlab.
I have read the FAQ section in the documentation site.
Describe the bug
I like the fact that formatting doesn't fail silently, but in combination with Jupyter's auto-saving mechanism this can get quite frustrating. I often leave cells in a half-broken state while editing; I know that this code is broken, I'll get around to that in a minute! 😛
But even if I'm diligently typing out perfect python code sequentially, auto-save might hit while I'm half-done typing out an assignment: my_var =
And 💥 I get a modal dialog alerting me to the fact that my code is "broken".
I am aware of the suppressFormatterErrors setting but that disables the errors altogether, which means I wouldn't be able to make sure my code is actually formatted before checking stuff into git.
In a perfect world, I'd want the errors to show up IFF I save manually.
I'm not sure if Jupyter's extension mechanism allows this distinction between automatic and manual saving of course, so what I'm asking for may be impossible.
In a related feature request, I'd love this to become a pre-commit hook in git. But I guess that's for a different time...
Diagnostic commands (probably not super useful here...)
$ jupyter labextension list
JupyterLab v3.4.8
/home/daan/miniconda3/envs/hfc/share/jupyter/labextensions
jupyterlab_pygments v0.2.2 enabled OK (python, jupyterlab_pygments)
@jupyter-widgets/jupyterlab-manager v5.0.3 enabled OK (python, jupyterlab_widgets)
@ryantam626/jupyterlab_code_formatter v1.5.3 enabled OK (python, jupyterlab-code-formatter)
$ jupyter serverextension list
config dir: /home/daan/miniconda3/envs/hfc/etc/jupyter
jupyterlab enabled
- Validating...
jupyterlab 3.4.8 OK
jupyterlab_code_formatter enabled
- Validating...
jupyterlab_code_formatter 1.5.3 OK
Screenshots
Nope, don't think so...
Additional context
This is related to #14 (which should be closed thanks to #195 IMHO) and #226.
The text was updated successfully, but these errors were encountered:
black-puppydog
changed the title
Formatting errors pop up during jupyter's auto-save, but can only be disabled globally
Feature request: disable pop-up errors only during auto-save
Oct 16, 2022
Sorry for the late reply, I haven't given this project much love, I just kinda lost steam over the years as I got increasingly burnt out, but lately I have gotten a second wind (perhaps only for a brief period...)
FWIW I am in middle to a big refactor for the project (mostly due to the evolution of jupyterlab's plugin tooling), this would be one of the things I can look at after that.
Without the the refactor, the development envrionment for this plugin is just nightmare-ish to use, so that is currently trumping all tasks.
Checklist prior to opening an issue
Describe the bug
I like the fact that formatting doesn't fail silently, but in combination with Jupyter's auto-saving mechanism this can get quite frustrating. I often leave cells in a half-broken state while editing; I know that this code is broken, I'll get around to that in a minute! 😛
But even if I'm diligently typing out perfect python code sequentially, auto-save might hit while I'm half-done typing out an assignment:
my_var =
And 💥 I get a modal dialog alerting me to the fact that my code is "broken".
I am aware of the
suppressFormatterErrors
setting but that disables the errors altogether, which means I wouldn't be able to make sure my code is actually formatted before checking stuff into git.In a perfect world, I'd want the errors to show up IFF I save manually.
I'm not sure if Jupyter's extension mechanism allows this distinction between automatic and manual saving of course, so what I'm asking for may be impossible.
In a related feature request, I'd love this to become a pre-commit hook in git. But I guess that's for a different time...
Diagnostic commands (probably not super useful here...)
Screenshots
Nope, don't think so...
Additional context
This is related to #14 (which should be closed thanks to #195 IMHO) and #226.
The text was updated successfully, but these errors were encountered: