After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672893 - bogus selection after undoing and redoing a cut operation
bogus selection after undoing and redoing a cut operation
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: General
3.12.x
Other Linux
: High normal
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
Depends on:
Blocks:
 
 
Reported: 2012-03-27 08:21 UTC by Vadim Rutkovsky
Modified: 2014-11-22 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix selection on redo (6.20 KB, patch)
2014-04-14 17:03 UTC, jessevdk@gmail.com
none Details | Review
Fix selection on redo (7.93 KB, patch)
2014-04-14 17:30 UTC, jessevdk@gmail.com
none Details | Review
Fix selection on redo (8.57 KB, patch)
2014-04-14 17:37 UTC, jessevdk@gmail.com
none Details | Review
Fix selection on redo (10.80 KB, patch)
2014-04-14 17:46 UTC, jessevdk@gmail.com
none Details | Review
Fix selection on redo (10.70 KB, patch)
2014-04-14 17:48 UTC, jessevdk@gmail.com
committed Details | Review

Description Vadim Rutkovsky 2012-03-27 08:21:23 UTC
Original report: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/964620

DistroRelease: Ubuntu 11.10
Package: gedit 3.2.3-0ubuntu0.1

Steps to reproduce:

- open gedit
- write the text: abcdefghijklmnopqrstuvwxyz
- select the portion from "e" to "i" included (5 characters)
- cut it e.g. by using ctrl+x => no text is selected now (ok)
- undo with ctrl+z => the un-cutted text is selected now (ok)
- redo with ctrl+shift+z

Expected: after re-doing, no character should be selected

Observed: => after redoing, the characters "jklmn" are selected, which are the one that occupy the positions previously occupied by the selected text.
Comment 1 Elia 2012-04-26 00:18:53 UTC
I can confirm this.

It is even more apparent (and annoying) with large chunks of multi-line text.

After re-doing with SHIFT + CTRL + Z text selection is offset and expanded to lines further down.

This means the document sometimes can even scroll up/down based on the size of the chunk that is cut and also the change in background color makes it much harder to determine what text was changes with the re-do operation.
Comment 2 Paolo Borelli 2014-04-13 20:20:41 UTC
This is a bug in gtksourceview undo manager. The bug can be reproduced with gtksourceview's test-widget program
Comment 3 jessevdk@gmail.com 2014-04-14 17:03:33 UTC
Created attachment 274290 [details] [review]
Fix selection on redo

This fixes the selection on redo by storing the to-redo
selection (i.e. current selection) on undo and vice versa.
This keeps the selection state consistent with the selection
whenever an undo/redo happens (since an undo can only be redone
and vice versa)
Comment 4 jessevdk@gmail.com 2014-04-14 17:30:03 UTC
Created attachment 274291 [details] [review]
Fix selection on redo

This fixes the selection on redo by storing the to-redo
selection (i.e. current selection) on undo and vice versa.
This keeps the selection state consistent with the selection
whenever an undo/redo happens (since an undo can only be redone
and vice versa)
Comment 5 jessevdk@gmail.com 2014-04-14 17:37:34 UTC
Created attachment 274292 [details] [review]
Fix selection on redo

This fixes the selection on redo by storing the to-redo
selection (i.e. current selection) on undo and vice versa.
This keeps the selection state consistent with the selection
whenever an undo/redo happens (since an undo can only be redone
and vice versa)
Comment 6 jessevdk@gmail.com 2014-04-14 17:46:48 UTC
Created attachment 274294 [details] [review]
Fix selection on redo

This fixes the selection on redo by storing the to-redo
selection (i.e. current selection) on undo and vice versa.
This keeps the selection state consistent with the selection
whenever an undo/redo happens (since an undo can only be redone
and vice versa)
Comment 7 jessevdk@gmail.com 2014-04-14 17:48:49 UTC
Created attachment 274295 [details] [review]
Fix selection on redo

This fixes the selection on redo by storing the to-redo
selection (i.e. current selection) on undo and vice versa.
This keeps the selection state consistent with the selection
whenever an undo/redo happens (since an undo can only be redone
and vice versa)
Comment 8 jessevdk@gmail.com 2014-04-14 17:51:49 UTC
Attachment 274295 [details] pushed as ee95815 - Fix selection on redo
Comment 9 Sébastien Wilmet 2014-11-22 14:49:41 UTC
For the record, there was a regression with this bug.

- select some text and delete it
- undo -> the selection is restored, ok
- click somewhere else or select some text somewhere else
- redo
- undo -> the selection is not restored correctly, the "somewhere else" is restored instead, which can be far away from the deleted text.

It's fixed in:
https://git.gnome.org/browse/gtksourceview/commit/?id=0c634b42dcc5c773b24fd8437400c82dcf41193a

(there has been a rewrite of the UndoManager in the meantime)