[v3] Select restored fragment upon undo / redo

marijnh commented

2012-11-02 06:38:08 +01:00

(Migrated from gitlab.com)

Select fragment of the text, Hit Delete, Hit Undo

Expected:

Fragment is restored and selected

Actual:

Fragment is restored, cursor position is set

All the editors I've been using are doing what is expected.

Select fragment of the text, Hit Delete, Hit Undo Expected: - Fragment is restored and selected Actual: - Fragment is restored, cursor position is set All the editors I've been using are doing what is expected.

marijnh commented

2012-11-02 10:17:00 +01:00

(Migrated from gitlab.com)

Which editors have you been using? I just tried several (chrome textarea, firefox textarea, chome url bar, firefox url bar, emacs, gedit) and none behaves in this way.

marijnh commented

2012-11-02 16:05:01 +01:00

(Migrated from gitlab.com)

Eclipse, Sublime, TextMate, Notepad, textarea I am currently typing in right now and virtually any editor?

marijnh commented

2012-11-02 16:28:26 +01:00

(Migrated from gitlab.com)

Must be some Windows tradition I'm not aware of.

I doubt though that they always select all the text that's modified by the undo. That sounds like it'd be a pain. Don't they just restore the cursor/selection position that was current when the history event was saved? That sounds like it might be a good approach.

Must be some Windows tradition I'm not aware of. I doubt though that they always select all the text that's modified by the undo. That sounds like it'd be a pain. Don't they just restore the cursor/selection position that was current when the history event was saved? That sounds like it might be a good approach.

marijnh commented

2012-11-02 16:47:00 +01:00

(Migrated from gitlab.com)

This behavior occurs in Firefox and Chrome for Linux as well (see jankeromnes's answer for more detail).

Personally, I think restoring the cursor/selection position from before the history event is the most user-friendly, but that may just be me.

This behavior occurs in Firefox and Chrome for Linux as well (see jankeromnes's answer for more detail). Personally, I think restoring the cursor/selection position from before the history event is the most user-friendly, but that may just be me.

marijnh commented

2012-11-02 16:47:52 +01:00

(Migrated from gitlab.com)

I did some tests in Linux (Kubuntu). I found the results somewhat surprising:

Never select restored text upon Undo:

CodeMirror
Vim
Chrome url bar

Only select restored text if it was selected before Undo:

Kate
Firefox url bar
textarea in Firefox

Always select restored text upon Undo:

Eclipse
Opera url bar
textarea in Chrome
textarea in Opera
Chrome devtools (except when editing HTML)

I did some tests in Linux (Kubuntu). I found the results somewhat surprising: Never select restored text upon Undo: - CodeMirror - Vim - Chrome url bar Only select restored text if it was selected before Undo: - Kate - Firefox url bar - [textarea](data:text/html,<textarea></textarea) in Firefox Always select restored text upon Undo: - Eclipse - Opera url bar - [textarea](data:text/html,<textarea></textarea) in Chrome - [textarea](data:text/html,<textarea></textarea) in Opera - Chrome devtools (except when editing HTML)

marijnh commented

2012-11-02 16:50:54 +01:00

(Migrated from gitlab.com)

This behavior occurs in Firefox and Chrome for Linux as well.

You must be using a different Chrome and Firefox then. Or maybe it's some deep GTK setting they are obeying that is set differently on my system.

> This behavior occurs in Firefox and Chrome for Linux as well. You must be using a different Chrome and Firefox then. Or maybe it's some deep GTK setting they are obeying that is set differently on my system.

marijnh commented

2012-11-02 16:52:54 +01:00

(Migrated from gitlab.com)

You must be using a different Chrome and Firefox then. Or maybe it's some deep GTK setting they are obeying that is set differently on my system.

Firefox 16.02 and Chrome 22 on Ubuntu 12.04, if that helps you narrow it down.

> You must be using a different Chrome and Firefox then. Or maybe it's some deep GTK setting they are obeying that is set differently on my system. Firefox 16.02 and Chrome 22 on Ubuntu 12.04, if that helps you narrow it down.

marijnh commented

2012-11-03 00:38:46 +01:00

(Migrated from gitlab.com)

I've added functionality where it reverts to the selection that was present when the undoable changeset was saved. That's as far as I'm willing to go. (Selecting precisely the changed text is problematic, firstly because undo events may affect multiple stretches of text when those were changed in a single operation, and secondly because I'm not currently tracking the precise start and end of the changes, and it'd require an overhaul and a more expensive data model for the changesets to keep that information.)

marijnh (Migrated from gitlab.com) closed this issue

2012-11-03 00:38:46 +01:00

marijnh commented

2012-11-03 09:33:03 +01:00

(Migrated from gitlab.com)

What you've done is good, but I don't think it is good enough:

Select a word
Hit Delete
Play with undo/redo - things work well, selection is restored
Now move cursor to a random place in the file
Play with undo/redo - selection is no longer restored

Side note: I don't think one should compare undo/redo behavior with the one in browsers, I'd rather target code editors. Popular ones I listed above seem to be consistent in this regard.

What you've done is good, but I don't think it is good enough: - Select a word - Hit Delete - Play with undo/redo - things work well, selection is restored - Now move cursor to a random place in the file - Play with undo/redo - selection is no longer restored Side note: I don't think one should compare undo/redo behavior with the one in browsers, I'd rather target code editors. Popular ones I listed above seem to be consistent in this regard.

marijnh commented

2012-11-03 10:52:14 +01:00

(Migrated from gitlab.com)

Can you provide a precise scenario in which it doesn't work as expected? I can't get the thing you describe to happen.

marijnh commented

2012-11-03 10:52:29 +01:00

(Migrated from gitlab.com)

(Might be that 1cbf1f6400 accidentally fixed it.)

(Might be that 1cbf1f64001b36dc7115f6a36c0f919f59c434fa accidentally fixed it.)

marijnh commented

2012-11-04 10:32:22 +01:00

(Migrated from gitlab.com)

The one I described is now fixed, there is one remaining though:

Select a word
Hit "a" to replace the word with single character "a"
Play with undo / redo, things work fine
Move cursor to another line
Play with undo / redo.

Selection is restored when undoing just fine, but cursor is not moved to after "a" upon redo.

The one I described is now fixed, there is one remaining though: - Select a word - Hit "a" to replace the word with single character "a" - Play with undo / redo, things work fine - Move cursor to another line - Play with undo / redo. Selection is restored when undoing just fine, but cursor is not moved to after "a" upon redo.

marijnh commented

2012-11-05 09:46:27 +01:00

(Migrated from gitlab.com)

See attached patch. I think that should make it behave as you intend -- when redoing, the selection is reset to the point where it was when the action was initially done.

marijnh commented

2012-12-03 10:27:55 +01:00

(Migrated from gitlab.com)

mentioned in issue #1038

Rows
Columns

[v3] Select restored fragment upon undo / redo #923