GNOME Bugzilla – Bug 622093
a minor inconvenience with mouse deselection
Last modified: 2021-06-10 14:24:46 UTC
Filed against vte, as it happens both in gnome-terminal and sakura. Deselection works correctly, if selection is started roughly on the cell border, however if a selection is started about in the middle of a cell, then that cell can't be deselected, that is: if I press and hold left mouse button to select a portion of a text in the terminal i.e. in the middle of a letter and select that portion, then as long as I hold the button, that letter can't be deselected by dragging the mouse, if I pull the selection in the opposite direction, the letter is still included in the selection.
That's intended. If you click in the middle of the letter, you probably want to select it. That's our best guess anyway. It wasn't always like that, but it was harder to make it what you want before. It wasn't clear where you have to click to get the start position you want...
The problem with that is that once you release the button, the letter goes into middle click paste, while if you could deselect it by dragging, that buffer would not be modified. For those that barely use a terminal, that may not be a problem, but otherwise it's an inconvenience (even if a minor one).
To make my point clear, I'm not arguing the letter being selected, but the lack of possibility to deselect it without selection buffer being modified.
Makes some sense. I'll look into it.
Indeed this is a bit annoying. Along with the drag threshold that makes it hard to select a single letter (you start by selecting two, then go back to select only one). Unfortunately many terminal emulators get it wrong. In my opinion, the reason for this is that when a click is forwarded to the application running inside the terminal, it's the charcell you click on that matters. And this confuses developers. Because, when you're highlighing text, it's not the cell that matters. In all the non-terminal applications highlighting is a smooth experience. For the y coordinate, it's text row where you clicked that matters (obviously). For the x coordinate, however, the closest boundary between two adjacent characters is located, that's where the selection begins or ends. IMO there's no reason terminals should provide a different user experience. And for this purpose, basically the boundaries have to be moved by half a cell horizontally, compared to as if the clicks were sent to the application. (Further special cases to consider for CJK/Tab.) I'll try to take a look.
(In reply to comment #2) > The problem with that is that once you release the button, > the letter goes into middle click paste, > while if you could deselect it by dragging, > that buffer would not be modified. Tried in gedit: while you can deselect by dragging a simple click, you can't do it with double or triple click selections, there's no way to escape from the buffer getting modified. I think it's okay if we aim for this in vte, too.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/1815.