Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Cursor jumps when manual save triggers autoformat of actively edited cell #291

Open
3 tasks done
GollyTicker opened this issue Dec 9, 2022 · 2 comments
Open
3 tasks done

Comments

@GollyTicker
Copy link

Checklist prior to opening an issue

  • 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

  1. Configure the extension to auto-format on save.
  2. Open a cell with some example python code in it
  3. Edit the code
  4. Save the notebook (via Ctrl+S) - while the cursor is still in the cell
  5. Cell is correctly auto-formatted
  6. Continue writing: But now, the cursor will be in the beginning of the cell rather than where one was writing. This breaks the user experience to some extent

There are many people (like myself) wo regularly save via Ctrl+S from years of habit of saving one's work. When doing this, it can be quite annoying, when the autoformatting resets the cursor. This doesn't happen with auto-formatting in other editors such as VS-Code, because they put the effort to work around these issues and put the cursor back to the new and correct position in the code.

I really like this extension, as I like to have the code automatically formatted during save - to improve readability and reduce time wasted on formatting. However, I would really appriciate, if the auto-format on save setting would restore the cursor position.

Diagnostic commands
Please attach the output of the following commands (please format them properly)

  • pip freeze
    • this list is really long and I am very sure, that this isn't related to the above bug, as it can be reproduced with just the basic installation. If you want, I can supply this nevertheless
  • jupyter labextension list
JupyterLab v3.5.1
<path-to-virtual-env>/share/jupyter/labextensions
        jupyterlab_pygments v0.2.2 enabled OK (python, jupyterlab_pygments)
        @ryantam626/jupyterlab_code_formatter v1.5.3 enabled OK (python, jupyterlab-code-formatter)
        @jupyter-widgets/jupyterlab-manager v5.0.4 enabled OK (python, jupyterlab_widgets)
  • jupyter serverextension list
config dir: <path-to-virtual-env>/etc/jupyter
    jupyterlab  enabled 
    - Validating...
      jupyterlab 3.5.1 OK
    jupyterlab_code_formatter  enabled 
    - Validating...
      jupyterlab_code_formatter 1.5.3 OK

Screenshots
When I want to add the statements a = 0 and b = 0 into the inner if-clause and I save in between the statements, then this happens:
jupyter-formatting-jumps

As you can see, the cursor resets to the beginning and if the user isn't focused on that, they'll accidentally write in the beginning.

Additional context
Maybe one can look into the existing auto-formatters to find out, whether they provide an API to return a sensible new cursor position given the original position before formatting. Otherwise there seems to be only the option to parse the AST and map the old position to a new position this way. The performance isn't going to be likely affected, since the code-blocks to be formatted as usually small.

What do you think?

@GollyTicker GollyTicker changed the title Cursor jumps when manual save triggers autoformat of actively edited cell Bug: Cursor jumps when manual save triggers autoformat of actively edited cell Dec 9, 2022
@GollyTicker
Copy link
Author

@ryantam626 What do you think about this? Is there a way others can help?

@ryantam626
Copy link
Collaborator

ryantam626 commented Feb 18, 2023

Hi, sorry for being MIA, I was dealing with too much and just had to disconnect.

I have some POC code that helps with figuring out what's the correct cursor location after formatting using python's ast module, but sadly it's not as exact as I want it to be, due to the limitation of ast. See: https://gist.github.com/ryantam626/b91577789c9aa283ba4adfd83c750886

If anyone could point me to how VS code deals with this, then it would be so much easier to implement.

edit: might have something with difflib.SequenceMatcher.get_matching_blocks, need some time to work out how to use it properly though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants