ryantam626 / jupyterlab_code_formatter

A JupyterLab plugin to facilitate invocation of code formatters.
MIT License
822 stars 52 forks source link

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

Open GollyTicker opened 1 year ago

GollyTicker commented 1 year ago

Checklist prior to opening an issue

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)

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 commented 1 year ago

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

ryantam626 commented 1 year ago

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.