Thanks for making a pull request to JupyterLab!

To try out this branch onbinder, follow this link:

Tests are failing. Will fix that.

Since this is a new user-facing term, I think we should have a short discussion about the name to make sure it:

• clearly and concisely conveys what we intend,
• is amenable to translation, and reasonably understandable to non-native English speakers
• perhaps extends to other documents we might have in JupyterLab that also may have this issue of localized vs global history.

It seems like we may be able to get a better term than "document-wide" - "wide" indicates scope, but also indicates a physical dimension, and to me it may not convey the idea of a combined global document structure and local edit history to everyone.

Some of these alternatives are certainly worse/more confusing, but in the interest of brainstorming and maybe triggering better ideas:

• "Document-wide history"
• "Comprehensive document history"
• "Combined document history"
• "Integrated document history"
• "Synthesized document history"
• "Unified document history"
• "Consolidated document history"
• "Federated document history"

I like "Unified document history"

Some of these alternatives are certainly worse/more confusing, but in the interest of brainstorming and maybe triggering better ideas:

Same here with

"Global document history"

"Global" was my first pick too, but it is actually non-ambiguous because it could also refer to changes in multiple documents (as in PyCharm for example, after you use refactoring which changes a variable name in several documents, the undo action in any affected document will undo the change in all the changed documents).

Maybe we should include the "cells" in the name? After all it changes how undo/redo works betweencells, so something likeUnified cells history?

Finally, it would be good to be consistent with the find/replace which can too be either searching in all cells or only in the selected cell. I don't know if the name for document-wide search & replace was discussed earlier, but maybe it would be good to discuss it now and make both undo/redo and search/replace have consistent terminology.

CI is green. I will wait one more day for feedbacks on the nomenclature. Based on previous feedbacks, it looks like to me the one to be selected is for nowenableUnifiedCellsHistory.

I tried it on binder and it does not work for me. Am I doing something wrong?

On my local env, withenableDocumentWideUndoRedo set tofalse,z is disabled andctrl+z is still working fine.

I don't think that this is the intended behaviour. I would likeenableDocumentWideUndoRedo to make notebook work as in 3.0, but the behaviour on your screencast indicates that this PR does something different. I think that with"enableDocumentWideUndoRedo": false:

• z should undo cell action such as move cell, cut cell, paste cell (as it was in 3.0)
• Ctrl +z should action within the cell and nowhere else (as it was in 3.0)

Were you trying to implement this as specified above, or were we thinking about different things?

To elaborate, my GIF is demonstrating thatCtrl +z affects both cells, a behaviour which was not present in 3.0 (was only introduced in 3.1) and was AFAIK the reason why we want to have option to disable document-wide tracking.

To elaborate, my GIF is demonstrating that Ctrl + z affects both cells, a behaviour which was not present in 3.1 and was AFAIK the reason why we want to have option to disable document-wide tracking.

Ok, I see.ctrl+z still undo across cells, which is not what we want. I have set to all existing y.js transaction false for the undoable attribute. I guess I will need to go a bit further to (1) use transactions at other places or (2) set the undoManager as null

Will have a look tomorrow, and thx a lot for having looked at this closer 👍

WithenableDocumentWideUndoRedo: false,z should do nothing. This is what we had defined in#10791 (comment). Just wanted ask again for confirmation.

WithenableDocumentWideUndoRedo: false,z should do nothing. This is what we had defined in#10791 (comment). Just wanted ask again for confirmation.

No, I don't believe that this is what users (including me) want. When giving a nod to:

If enableRtcUndoRedo is false, we disable RTC (Y.js) undo/redo for everything (cells actions, outputs..), but the former CodeMirror ctrl+z remains.

I meant that I agree that we should restore the 3.0 behaviour. Sorry if my response was misleading, I could have explained it better (I did not see the above sentence as contradicting restoring the 3.0 behaviour).

Also, as the separation between cell undo/redo and editor undo/redo was there for many many years (in both notebook and lab), I just don't think we should remove it in a minor release. I am not saying that it should remain forever, but if we want to enable seamless migration path from Jupyter Notebook to JupyterLab (e.g. via RetroLab), we should not change this fundamental piece of UX.

I meant that I agree that we should restore the 3.0 behaviour. Sorry if my response was misleading, I could have explained it better (I did not see the above sentence as contradicting restoring the 3.0 behaviour).

So we want to keep RTC undo/redo for cell movement, right? Only the cell content should be "own-cell" like before (with the CodeMirror mecanism), or "cross-cell" (with the RTC mecanism).

I will rewrite this PR to take this into account. Thx for clarifying the requirements.

Also if the intent is to have undo/redo like in jlab 3.0 in a cell working in RTC case, we would need to go to multiple undomanager as highlighted on#10791 (comment)

My understanding is that having it work like in jupyerlab 3.0 does not imply RTC, this is why I have writtenwith the CodeMirror mecanism, implying that it is not with RTC.

Can anyone confirm this assumption?

I thought from our discussion last Wednesday that we were going to provide a setting that reverted to the 3.0 undo behavior, but using the yjs undo mechanism (and multiple undo managers for yjs). Otherwise, as Kevin pointed out, the undo would be pretty finicky with RTC (i.e., undoing an edit in a cell would undo other people's edits, rather than just your own). And in this case, the cell-level "undo" would actually just be a new revert of the specific change, rather than an unwinding of the undo stack?

...and multiple undo managers for yjs...

This is a much bigger implementation than having the simple fallback to code mirror. I don't know how many RTC are in the fields, and how many would want to disable the document-wide undo/redo.

It is also a bit hard for me to imagine the code change to support one undi/redo manager per cell.

eg., for now, you just call "redo()" method without parameters. I don't see how the shared model implementation could know which undo/redo manager to use. We would even need to change the codemirror and codeeditor api. Please correct me if I am wrong.

This is why as middle-approach, I was thinking/proposing the fallback to codemirror undo/redo.

Did anyone save minutes from last weeks discussion?

eg., for now, you just call "redo()" method without parameters. I don't see how the shared model implementation could know which undo/redo manager to use. We would even need to change the codemirror and codeeditor api.

I guess we may need to modify the API indeed, but as long as we are expanding API in backward-compatible way, that should be ok, as we are aiming for this one to go into 3.2, right?

The idea is to have anundoManager for every cell. This way, we can have the old behavior using RTC as Jason commented here:#10949 (comment)

Instead of using the documentundoManager, we need to create a newundoManager on every cell. We are adding the documentundoManager to the cell here:

@echarles, I can work on this if you prefer.

Thx@hbcarlos for the pointers. I had started something in that direction. I keep you updated on my progress.

A point that I brought up in the weekly dev meeting:

• Each Yjs doc will have a global unified history regardless of how many undo managers are used and what part of the doc they are mapped to.
• The undo managers are a per-end-user tracking mechanism, whereas the global history is universal across all users, so individual users can make different choices about how undo/redo is handled, all while there is still a universal global history.

Based on this, I think there are two things that need to be named:

• The global, universal doc history of the Yjs doc.
• The per user undo/redo managers that map to different parts of that Yjs doc, or the whole.

might the i18n failure be because a schema changed?

Yes the i18n check is failing as this PR is introducing new translatable strings in the settings schema.

Yes the i18n check is failing as this PR is introducing new translatable strings in the settings schema.

What is the action to take to fix that? Not sure here after readinghttps://jupyterlab.readthedocs.io/en/latest/developer/internationalization.html.

Do I need to open something onhttps://github.com/jupyterlab/language-packs?

I think that no action is needed (this check is just to warn us about changes), but it highlights that this PR is not targeting master branch - it would have not failed on master.

Yep we can merge this one.

The i18n check could be further improve to check that there is not yet a final release on X.Y.Z. But this is gonna be tricky to achieve.

It could check the current version withpython setup.py --version and compare it to a regex like we dohere

@meeseeksdev please backport to 3.2.x

Can't Dooooo.... It seem like this is already backported (commit is empty).I won't do anything. MrMeeseeks out.

Thx@blink1073 for the merge of this experimental feature. This PR was for 3.2 branch. I guess meeseeksdev can backport to master.

@meeseeksdev please backport to master

Thanks again@echarles!

Does merging this close#10791?

Thank you so much for working on this! It does seem a lot better to help users transition from the 3.0 behavior.

I noticed a few things:

1. Testing out moving cells, it seems that when I move a cell, I not only lose any undo history, but actually undo does not work for any new changes to the text after the move, which I was not expecting. Is this expected?
2. It seems a bit odd that a setting that is now clearly labeled as "experimental" defaults to true. Usually experimental settings default to false, i.e., off, and are there for adventurous users to turn on if they wish.

Does merging this close#10791?

I don't think as we need a more robust solution which depends on#11035

Thank you so much for working on this! It does seem a lot better to help users transition from the 3.0 behavior.

Thank you for testing@jasongrout

Testing out moving cells, it seems that when I move a cell, I not only lose any undo history, but actually undo does not work for any new changes to the text after the move, which I was not expecting. Is this expected?

This is not ideal, but indeed, you loose undo capability on the moved cell. I have tried to overcome that, but was not able to add an undomanager on the clone object. I can give it another try, any further input will be helpful.

It seems a bit odd that a setting that is now clearly labeled as "experimental" defaults to true. Usually experimental settings default to false, i.e., off, and are there for adventurous users to turn on if they wish.

WouldexperimentalDisableDocumentWideUndoRedo: false be better?

Would experimentalDisableDocumentWideUndoRedo: false be better?

Yes, please. I missed the fact that it wastrue in the review. Once that is in, I will cut the RC.

Yes, please. I missed the fact that it was true in the review. Once that is in, I will cut the RC.

@blink1073 I have openedhttps://github.com/jupyterlab/jupyterlab/pull/11215/files for this.

@adpatter FWIW what you wrote feels more like a bug than a feature. I think document wide history tracking should scroll to where the undo happens and that would mollify some concerns. Likely this was overlooked.

This PR gives users the ability to revert back by the previous undo model by setting experimentalDisableDocumentWideUndoRedo.

Re: above, I think that this PR had a misleading title, likely due to a typo, I now changed it to avoid misunderstandings.

The undo functionality that I described above is not document wide undo. It is harm.

@adpatter The case you have described is what we call document-wide history tracking and is the default behavior in 3.1 and 3.2. This PR allows a user to disable that behavior and roll-back to pre-3.1 where the undo is done cell by cell, and not on a document-wide level. I hope this clarifies a bit, and sorry for the misleading title. Of course, you are welcome to open a new issue to further discuss how the case you describe should be treated (e.g. with scrolling or any other option).

This pull request has been mentioned onJupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/ann-jupyterlab-3-2/11248/1