Mouse selection should be based on horizontal center of characters

[jscheid]

I'm using Kitty 0.12.1 on OS X 10.12.6.

When I use the mouse to select text moving from left to right, the right-most character appears to get selected as soon as the mouse X position is beyond the left edge of the character. It would be better if it gets selected only when the mouse is beyond the horizontal center of the character. The same goes for the other end of the selection

For what it's worth, that is how Terminal.app works.

Here is some gratuitous ASCII art:

 __        __
 \ \      / /
  \ \ /\ / / 
   \ V  V /  
    \_/\_/             
 ^    ^
 |    |
 |    +--------- It would be nice if W only got selected when mouse crosses this point
 |
 +------------ W currently gets selected as soon as mouse crosses
               this point (coming from left)

Let me know if this doesn't make sense and I'll make a screencast.

[kovidgoyal]

I dont understand how that would work. What if I entered a cell vertically instead of horizontally? Or if the selection is just starting and there is no history of movement to detect whether the selection is going form left to right or right to left.

[jscheid]

Good question, I think something like this, in pseudo code:

if startRow < endRow or (startRow == endRow and start.x < end.x)
  startColumn = round(start.x - 0.5)
  endColumn = round(end.x + 0.5)
else
  startColumn = round(start.x + 0.5)
  endColumn = round(end.x - 0.5)
endif

As for "the selection is just starting" -- don't you wait anyway before going into selection mode until the mouse has moved a certain distance, so that you can distinguish clicks?

If you have Terminal.app around I'd suggest to set font size very large (72pt say) and play a little bit with it to see what I mean. If you don't, let me know and I'll figure out how to make a screencast GIF for you.

[jscheid]

I think maybe a better way to describe it is that the selection should be based on the gaps/edges between characters rather than the characters themselves. So for example, if you have "ABC" and the mouse is in the right half of A or the left half of B, then the edge between A and B is where the selection should start.

[kovidgoyal]

Wouldn't that mean you cannot select the first character in a line when going left to right and the last character in a line going right-to-left? I suppose those could be special cased, but I am not entirely clear as to what the benefit of this mode of selection is? I would find it fairly confusing if I clicked on the right half of A and the next character got selected.

[jscheid]

Ok so take for example this line:

ABCDEF

If I start between A and B (i.e. between 0.5 and 1.5 characters) and move to the right, then B should be the first character selected.

If I start between A and B and move to the left, then A should be selected.

If I start in the left half of A (i.e between 0 and 0.5) and move to the right, then the selection should start with A.

I would say that is a much more natural way to select, and I'm pretty sure it's how selection works in the majority of terminals and text editors.

[kovidgoyal]

So to summarize, the algorithm seems to be select a character if the mouse is in the latter half of the character (where latter half is defined by the recent horizontal motion of the mouse), is that correct?

[jscheid]

Yes pretty much, but it doesn't depend on recent motion, it only depends on start and end position, i.e. on whether you select text forwards or backwards.

Again, I think the best way to conceptualize it is to think of the selection as stretching between the (zero-sized) space between characters, rather than the characters themselves.

[kovidgoyal]

OK, personally I dont much see the point, but then I'm not a big mouse user, so I wont claim any special expertise on how mice should behave :)

The selection code is in mouse.c it would require some refactoring to implement this algorithm since the mouse handling code currently tracks only the cell the mouse cursor is on, not its offset within the cell.

SO maybe I'll get to it someday, in the meantime, patches are welcome. If you do want to implement it, fele free to ask if you need help with anything.

[jscheid]

Ok, thank you. I might take a look tonight to see how much work it would be.

[jscheid]

Is it possible that you can't currently select just a single character, that you have to select at least two?

It seems to be so because of (start_x == end_x && start_y == end_y) in

kitty/kitty/screen.c

Lines 1492 to 1494 in 0195e7f

	is_selection_empty(Screen *self, unsigned int start_x, unsigned int start_y, unsigned int end_x, unsigned int end_y) {
	return (start_x >= self->columns || start_y >= self->lines || end_x >= self->columns || end_y >= self->lines || (start_x == end_x && start_y == end_y)) ? true : false;
	}

[kovidgoyal]

Yes, it is the case. If you want to remove it, you can probably do so safely by changing the check to

(start_x == end_x && start_y == end_y && start_x && start_y)

the idea is to exclude the empty selection which is initialized with all parameters zero

[jscheid]

Hmm... I've got something working, but it requires a slight change to the semantics of screen_update_selection. Are there many plugins I'd break with it?

[kovidgoyal]

No plugins depend on selection semantics, but there are several selection modes, such as right click to exten selection, multiple clicks to select words/lines, etc. https://sw.kovidgoyal.net/kitty/#mouse-features