Created attachment 94625 [details] [review]
Use ceil()-1 instead of floor().

Can you try this patch? It changes the selection behaviour to lag behind the cursor instead of including the character partially beneath the cursor. I'm not sure how this fits in with the HIG though.

Now I'm using vte with this patch, and I don't like it either.

When you click and start moving the mouse to the left, it usually still highlight two characters at once.

When moving the mouse to the right, sometimes it highlights the next cell when I reach its left edge, sometimes only when I fully pass over this cell. As a result, sometimes (randomly) the selection grows by two cells. I cannot systematically reproduce it, but I also had this when using keyboard mouse emulation (ctrl+numlock followed by numpad keys) instead of real mouse.

There is often a huge (one cell wide) hysteresis: a cell only gets highlighted if I reach its right edge with the mouse, but I have to move the mouse to its left edge for the selection to leave this cell.

Furthermore, I also often face a situation when this behavior clearly depends on the y-coord of the mouse within the cell: if it is in the upper half of the cell, then the next character is highlighted as soon as the mouse enters it, but if it is in the lower half, the mouse has to reach the right edge of this cell to be highlighed.

Also I do not think that altering selection bounderies when the mouse is at cell boundary is a good idea. When I want to highlight certain text, I try to move the mouse to the end of that text, which of course has a plus-minus few pixels accuracy how I can move it, and I always expect that text to be selected.


I examined how certain other apps behave (namely: text editing field of gedit with huge font, normal selectable text in GTK apps' about window, and opera's browser canvas), they are all sane and consistent. Here's the algorithm:

For both of the mouse click position and the current mouse position, do the following: The y coordinate is only used to determine which text row we are in, otherwise its exact value is irrelevant. The x coordinate is rounded towards the nearer cell boundary within that row, that is, if you click on the left half of a letter then it is rounded downwards, if you click on the right half then upwards. The selection is the text between these two points.

Some important properties of this algorithm that are not fulfilled by current vte, but should be:

- There's no hysteresis, no history, it's irrelevant where the mouse has been earlier, only the two endpoints (where you have clicked and where your mouse is now) matter,

- these two coordinates are interchangeable too, the selected text shouldn't differ if you swap the points where you click and release the mouse,

- if the user click in the space between two letter or very close to it (that is, on the very edge of a letter), the selection should start there, no matter if he clicked with an offset of a very few pixels. So the critical mouse x-coordinates where the selection changes should be in the middle of letters, not between them.

Btw vte-0.12.2 used a different algorithm, but that was quite usable too.
(I haven't tried versions between 0.12.2 and 0.16.8.)

2008-12-02  Behdad Esfahbod  <behdad@gnome.org>

        Bug 471480 – select single character
        Bug 110371 – Cannot select newline at end of full line

        * src/vte-private.h:
        * src/vte.c (find_start_column), (find_end_column),
        (vte_terminal_start_selection), (math_div),
        (vte_terminal_extend_selection):
        Make selection work more I-beam-like.