GNOME Bugzilla – Bug 722635
selection is moved on a different part of the text when vte widget is resized
Last modified: 2014-04-06 18:26:44 UTC
Created attachment 266787 [details] Screencast of the problem Select a text resize the terminal window observe the selection is no more on the selected text, eventually find the selection moved to another part of the text. (see the screencast attached) I guess this is a regression with the reflow functionnality that lend into vte recently.
Created attachment 266797 [details] [review] Fix: update selection on rewrap Indeed, it didn't occur to me to update the selection. Nice catch, thanks very much! :) Could you please test the attached patch? I believe it fixes the problem.
Created attachment 266799 [details] [review] Fix: update selection on rewrap (v2)
Hmmm, not good if the selection ends with a complete line (highlighing all the way to the right margin).
There are two problems with highlights finishing with a complete line: - selection_end is inclusive (the last char belonging to the selection) rather than exclusive which would sound more logical to me. Changing the semantics all over the code seems a bit risky; probably incrementing before rewrap and decrementing after is an easy workaround. - there's a confusion that a selection finishing with a complete line might be stored in two different ways. If you move the mouse to the right, it will be stored as (row = that row, col = terminal's width), but if you move the mouse to the left then it's stored as (row = the next row, col = -1). I'm yet to understand if it makes sense to maintain both possibilities, or if there's any difference between the two. It would simplify my life a lot if I could just go with the (row = next row, col = -1) way of storing.
Created attachment 266805 [details] [review] Fix: update selection on rewrap (v3) I hope it really works okay and I didn't break anything :)
Fixed in vte-0-36. Keeping open for vte-next.
Oops, not fixed yet. selection_end.col can be less than -1 and then it breaks. Probably selection_start.col can also be less than -1.
Okay, this one's fixed too. (Only in vte-0-36.)
One more bug: The start coordinate was not confined to be inside the visible area (as it is done in from vte_terminal_extend_selection() for the end point). Fixed now in vte-0-36.