Cudatext: Undo/Redo behaviour. Discussion

[xcme]

When undo/redo is performed on the same screen it's obvious and we always can recheck it by repeating Ctrl+Z/Ctrl+Y. But if we reverting any change which is placed behind the screen we don't see what exactly has happened. And if we press Ctrl+Z/Ctrl+Y it looks as the caret jumping, despite it does all the job in background.

Can we improve this behavior somehow? It could be:

1. If CT have to scroll the screen while reverting change, it just scrolls the screen after first Ctrl+Z/Ctrl+Y and do the change after second Ctrl+Z/Ctrl+Y.
2. It could jump to the position, wait for 0.2 sec and then revert/redo the change.
3. Any other option?

The goal is to have visual control over my own actions.

[JairoMartinezA]

Hi @Alexey-T

I don't know if this functionality is still an experimental feature in GitHub, but some months ago, GH released the Discussion

Considering there are some "topics" that are not a really an "issue", I know you currently have the label _talk_. Just for your consideration.

[Alexey-T]

it just scrolls the screen after first Ctrl+Z/Ctrl+Y and do the change after second Ctrl+Z/Ctrl+Y.

this is bad of course: user will think "i pressed undo, so undo is made!" and he has a trap. macros (with undo) won't work... I dont know. See how other IDEs do this thing. IDEs, not simple editors

[xcme]

Another unexpected behaviour:

1. Type something on line, for example, 100
2. Press Ctrl+F (I use 'Hi' but don't know if it's important) and find any text on line 25, for example
3. Go to main window and try Ctrl+Z/Ctrl+Y

You can see it undoes/redoes editing on the line 100, but moves the caret to line 25 every time. So, all the changes it does are completely unclear because they're out of the screen.

[Alexey-T]

I cannot repro this jump-- on 'undo' , editor scrolls to line 100 (with undo positon) and not to line 25. maybe steps of repro are not complete?

[xcme]

undo_redo.zip

Watch the minimap. There you can see another line but in the main window it isn't obvious what's going on.

[xcme]

I also got situations when I completely lost another line (no action after redo) but can't reproduce anymore.

[Alexey-T]

I dont get how do you get jumps in editor line25--line100, you press ctrl+Z and editor does jumps? or do you run Undo (one jump), Redo (jump), Undo, Redo, Undo, Redo?
I tested on Win10, no jumps.

[Alexey-T]

I completely lost another line (no action after redo) but can't reproduce anymore.

I see that. I will post new bugreport

[xcme]

I dont get how do you get jumps in editor line25--line100, you press ctrl+Z and editor does jumps? or do you run Undo (one jump), Redo (jump), Undo, Redo, Undo, Redo?
I tested on Win10, no jumps.

• First jump is related to search. I pressed Alt+N and then Enter in the search dialog, so it jumped to the first match.
• Then I pressed Ctrl+F to leave search dialog.
• Then I pressed Ctrl+Z. It deletes another line as the last change.
• Then Ctrl+Y (I use Ctrl+Y for redo) returns the last change but moves caret to fff

[Alexey-T]

will check that soon.

[xcme]

It seems #3259 is related to this also.

[xcme]

Btw, in regards to initial subject, could you also try this after fixing jumping issue?

It could jump to the position, wait for 0.2 sec and then revert/redo the change.

[Alexey-T]

I see it's OK work of undo/redo. yes, 'redo' moves caret after last change. it is logic which was asked by ppl. most/each 'undo/redo action' moves caret.

[Alexey-T]

so, I am lost - what does need the fixing?

[xcme]

Two things to fix, from my point.
1. The first one is described in the initial post. At the time being undo/redo looks like:
- undo/redo in background
- jump to the right position

I propose just to change sequence:

• jump to the right line
• wait for very short period
• undo/redo in the visible area
• jump to the right position

This is for cases when user works on lines 25 and 150, for example. I mean, when jump is unavoidable. But with the new logic it gives user an idea of what's going on, because he can see it.

1. The second case is describer here - #3248#issuecomment-803653323. The cares should jump to undo/redo position but it jumps on the search position instead.

[Alexey-T]

I like the idea-1. Todo. It will make editing comfy.

Idea-2-- pls, make new issue? and your link don't work in firefox. (link to special comment)
this issue is overheated

[xcme]

@Alexey-T I also use firefox, just don't know how to link comment here. Created new issue for the second case - #3261.

[Alexey-T]

Made some work on idea-1, let's test:
http://uvviewsoft.com/c/

[Alexey-T]

updated the beta; made some tweak.

[Alexey-T]

updated again; added option for undo-pause (readme.txt).

[xcme]

Yes, it's a progress, but should be tested also. It seems that #3258 still there (it loses empty lines on Ctrl+Z).
Another thing I have noticed - if we were on line 20, then edited line 30 and pressed Ctrl+Z it jumps back to line 20. On the current 'prod' release it keeps caret on line 30 after undo and I think it's right.

And question:
Should we use delay in case we perform undo/redo in visible area? Ate the moment I vote 'no', because I think people are OK with current behaviour. But when jump is unavoidable it's needed. Or it can be optional?

I think other 'team' can participate also (@JairoMartinezA @kvichans @halfbrained @tmsg-gh and others) because it's small, but very important change.

[Alexey-T]

Another thing I have noticed - if we were on line 20, then edited line 30 and pressed Ctrl+Z it jumps back to line 20. On the current 'prod' release it keeps caret on line 30 after undo and I think it's right.

I don't see that: on empty doc, I edited line 2, then ENTER N times, editted line 10. Undo: caret is left in line 10 after undio of line 10.
Note: I use 'undo_grouped' option all times.

[Alexey-T]

Should we use delay in case we perform undo/redo in visible area? Ate the moment I vote 'no',

Let's see what 'team' willl say; I can adjust that!

[JairoMartinezA]

I am a little busy today and tomorrow to validate all the issue. Just to consider if the change is a "major change" and can impact other functionality, maybe you can wait with the "beta" for a week (suggestion) in order we can have enough time to validate and give our feedback. 👍

[Alexey-T]

Should we use delay in case we perform undo/redo in visible area? Ate the moment I vote 'no',

@xcme Ok, I adjusted it as suggested

[xcme]

It seems it works, but see my comment here. Sometimes it considers caret movement as undo action, thereby sometimes in undoes caret movement, sometimes the change itself.

[xcme]

Yes, but it consider it as a separate action only for second and further pressing. Do you need video for better understanding?

[Alexey-T]

is it posted to another issue? #3261. if yes, let's close this one?

[xcme]

Let's keep it for a while. The issue in #3261 prevents to test this fix well. For the first glance it look good, but let's deal with other related issues. I think the current one should be closed last. And @JairoMartinezA may have a chance to test it also :)

[halfbrained]

It is nice that view doesn't jump immediately after undo/redo, but after a delay...

But now (in the latest beta) you cannot redo after mose click. (type something -> undo -> mouse click -> redo doesn't work)

[xcme]

It is nice that view doesn't jump immediately after undo/redo, but after a delay...

Btw, from my point it should jump immediately, but there should be a delay between jump and the undo/redo action itself. It allows the user to get and idea what's going on, because he has a chance to see that part that will be changed. Do you mean that or something else?

[halfbrained]

Do you mean that...

I suppose I did... the result of Undo/Redo are more visible now, but the behavior is a bit confusing :)

The disappearance of Redo after a click is a much bigger problem for me

[Alexey-T]

But now (in the latest beta) you cannot redo after mose click. (type something -> undo -> mouse click -> redo doesn't work)

fixed now. uploading a new beta in 5 minuts.

[kvichans]

@xcme Do you know command go to last editing pos? I use it to go back instead undo+redo (old my way)

[xcme]

I use it to go back instead undo+redo (old my way)

But why?

[kvichans]

I use it to go back instead undo+redo (old my way)

But why?

I set Alt+Home to go to last editing pos and use it many times every day

[xcme]

I mean why do you use it instead of undo/redo?
But I will think to use it in parallel also, thanks.

[xcme]

@Alexey-T, it seems all issues were fixed. Take a look at #3270 and after we can have new public beta for test. Please, don't release it in the prod right now, because we need to test it better. I will install new beta as my main version and try to make some code :)

[xcme]

We also can describe the current logic and last changes to let people know what they should check if they want.

[Alexey-T]

We also can describe the current logic and last changes

do you mean "in the wiki"? then pls provide the En text. I will put it to wiki

[xcme]

do you mean "in the wiki"? then pls provide the En text. I will put it to wiki

No, at the moment I'm talking about beta testing. We have lot of separate issues related to undo/redo and you have performed so many fixes, so people who weren't watching just don't know what to test. Could you combine all changes you did in logic in one post?

[Alexey-T]

I am tired, sorry. maybe you can do it

[Alexey-T]

Ok let's test the public beta for n days, until April maybe.

[xcme]

Ok, let me prepare some list as a template. Then you can update it:

So, new beta has major changer in undo/redo logic:

1. Caret movements were considered as actions that could be cancelled/repeated. It led to unneeded caret jumps. Now it looks more like undo/redo manages the content, not caret.
2. If last change was performed in area which isn't visible now, then undo/redo actions will highlight for a while the line and insert a short delay before the undo/redo action.
3. New options undo_for_caret_jump and undo_pause were added.
4. Paste followed by other editing were considered as single action, so undo cancelled both the pasting and the editing at once. Now these actions are separated and it's possible to undo/redo them in turn.

[xcme]

Ok let's test the public beta for n days, until April maybe.

Would you create a new issue for testing the beta?

[Alexey-T]

yes, I will.

[Alexey-T]

closing.