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

Paste should have a separate undo event (3.1 regression) #10928

Closed
krassowski opened this issue Aug 26, 2021 · 3 comments · Fixed by #11471
Closed

Paste should have a separate undo event (3.1 regression) #10928

krassowski opened this issue Aug 26, 2021 · 3 comments · Fixed by #11471
Assignees
Labels
bug pkg:shared-models status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Real Time Collaboration

Comments

@krassowski
Copy link
Member

Description

Since JupyterLab 3.1 the history aggregation leads to the undo event often removing way too much code. In particular, uno after paste event, often remove text written prior to undo event, which is quite annoying when trying to correct text written prior to paste.

Reproduce

JupyterLab 3.0:

jl-3 0

JupyterLab 3.1:

jl-3 1

Expected behavior

As in JupyterLab 3.0; paste should always be a history event of its own that can be undone irrespective of previous changes.

Context

  • Operating System and version: Linux Ubuntu 21.04
  • Browser and version: Chrome 92
  • JupyterLab version: 3.1.9
@hbcarlos
Copy link
Member

During the lab meeting, we discussed the capture timeout on the undo manager and decided to use the default (500ms); since that's what most editors do. But make it configurable to allow undoing character by character.

As most editors do, Yjs keeps stacking inputs in the undo manager until the user stops writing for 500ms, then groups all the inputs as one undoable action. For the shared model, the paste action is just another input.

Maybe we could detect a paste action by checking the input length, but I'm not sure if that would affect other input actions.

@krassowski
Copy link
Member Author

Maybe we could detect a paste action by checking the input length, but I'm not sure if that would affect other input actions.

In CodeMirror the change: CodeMirror.EditorChange can havechange.origin === 'paste' which I use to detect paste events in the LSP extension. Could this be used here as well?

During the lab meeting, we discussed the capture timeout on the undo manager and decided to use the default (500ms); since that's what most editors do.

Sorry I could not attend. I am not convinced by the argumentation if it is based only on Google Docs as previously mentioned. For one, google docs does not have autocompletion (I think), then it also has auto-correction (which we do not have as we are not operating over a limited alphabet - variable names can be arbitrary).

But make it configurable to allow undoing character by character.

Can we make the timeout configurable, so that 0 = character by character, and then the user could set it to 200 if they type fast or 800 if they type slow?

@hbcarlos
Copy link
Member

In CodeMirror the change: CodeMirror.EditorChange can have change.origin === 'paste' which I use to detect paste events in the LSP extension. Could this be used here as well?

That could be really useful. Thanks!!

I am not convinced by the argumentation if it is based only on Google Docs, as previously mentioned.

No, it is not based on Google docs only. During the meeting, some people tried multiple editors and text areas on browsers, all of which do the same.

Can we make the timeout configurable so that 0 = character by character, and then the user could set it to 200 if they type fast or 800 if they type slow?

I think we can, but I need to try.

@fcollonval fcollonval self-assigned this Sep 24, 2021
dmonad added a commit to dmonad/jupyterlab that referenced this issue Nov 15, 2021
meeseeksmachine pushed a commit to meeseeksmachine/jupyterlab that referenced this issue Nov 16, 2021
jtpio pushed a commit that referenced this issue Nov 16, 2021
@github-actions github-actions bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label May 16, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug pkg:shared-models status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. tag:Real Time Collaboration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants