gui: improve mouse text selection

[davidrios]

• implement mouse press capture between the terminal and UI, so when you
  start selecting text from the terminal the tabs won't activate and
  vice-versa
• selecting from the top and bottom lines won't scroll the viewport
  anymore, it will only scroll if the mouse is moved out of line bounds
• change cell selection so that it behaves like text selection usually
  does in other popular software

refs: #1199
refs: #1386
refs: #354
possibly: #1589

[davidrios]

@wez What do you think of this approach for testing?
davidrios@c8a2764
I moved some things to traits to be able to implement them in testing.

[wez]

I don't have time for a full review right now, but this caught my eye: why is the type changing? I'm pretty sure that this can never legitimately be negative. @AutumnMeowMeow: can you confirm?

[davidrios]

The idea is for them to be able to have negative values, to encode information about the mouse leaving the area. For instance, y = 0 means that the cell is the top one, and y pixel offset = -10 means the mouse is 10 pixels above that cell. They'll only have negative values when x/y are = 0.

[AutumnMeowMeow]

(Sorry if incoherent, watching Matrix 4 while drunk... 🍷🔫🔫🔫👭🔫🔫🔫🔫🔫🔫🔫🔫🔫👭🔫🔫🔫🔫🔫🔫🔫🔫🔫💞💞)

The terminal should not be reporting negative values (they are required to be positive in CSI sequences), but at one point xterm itself was reporting negative when the mouse was captured (button down) and dragged above the top-left corner of the text area -- when using SGR-Pixel mode. I didn't report that as a bug, someone else might have. Let's see if I can find that thread.... here: contour-terminal/contour#574 (comment) Of course j4james is the real expert. :-)

Within wezterm, the offset values could work the same whether positive or negative values.

[davidrios]

Note that the negative offset is only used internally/where it makes sense, in other places I've clipped it to positive only values, like here:

wezterm/term/src/terminalstate/mouse.rs

Line 72 in be567fb

(event.x * (self.pixel_width / width)) + event.x_pixel_offset.max(0) as usize + 1,

[davidrios]

On the topic of those offsets, they have an unexpected (to me) behavior, so I'm not sure if it's a bug or could have weird side effects. These are the values reported:

The blue cells are what is reported in the x property, because of the rounding here:

wezterm/wezterm-gui/src/termwindow/mouseevent.rs

Lines 85 to 87 in be567fb

	// Round the x coordinate so that we're a bit more forgiving of
	// the horizontal position when selecting cells
	x.round()

, which is done so mouse selection feel more natural, yet the x_pixel_offset is calculated based on the real cell, so the reported cell, offset are not in sync.

I'm thinking maybe it would be better to always report the real cell and offset, and let the code that's using them do the relevant processing.

[wez]

@AutumnMeowMeow: what do you think about these positioning offsets; are they actually what you want to see in the report sent to your app?

[wez]

What do you think of this approach for testing?

I think it looks good! Just the right amount of trait use IMO.

There are some selection bits in the term subdir that are probably dead code now, but date back to when selection was managed by Terminal rather than the GUI. There might be some stuff there that is worth moving into the gui crate if you'd like to augment selection tests: https://github.com/wez/wezterm/blob/main/term/src/test/selection.rs

[davidrios]

Anyway, I'll create another PR for the tests and some other related changes, so this one is ready for merging (as soon as all discussions are resolved).

[wez]

I think this looks good! Thanks!

[wez]

Thanks!