action_print() is in the hot path, and having if-statement here *does*
have an impact on performance.
Much more so when that if-statement involves a functional call to
wcwidth().
Closes#330
The main surface is the *only* IME capable surface we have. If the
compositor is sending an ime::enter event for another surface, it is a
compositor bug, not a foot bug.
When the application is grabbing the mouse, we require ‘shift’ to be
pressed to be able to use foot’s mouse bindings. Otherwise the mouse
event is sent to the application.
This wasn’t being enforced consistently; each and every mouse **only**
action was checking the mouse grab state, but e.g. *primary
paste* (which can be used as both a key binding and a mouse binding)
was not.
The fix is actually quite simple: don’t even try to execute *any*
mouse bindings when the application is grabbing the mouse (unless
shift is pressed).
This fixes an issue where e.g. middle mouse button events (using the
default mouse bindings) were never seen by any mouse grabbing client
applications.
To reproduce issue:
- Launch an IME from inside foot
- Type in some preedit text
- Use Ctrl-C to close the IME
- IME text stays in terminal until focus is changed
Before passing the pasted text to the decoder, we now replace \r\n,
and \n, with \r.
The URI decoder was looking for a \n, which meant we failed to split
up the list and instead pasted a single “multi-line” URI.
We failed to convert the byte-indices to cell indices, resulting in a
box cursor covering the entire pre-edit string.
Note that in addition to fixing the translation from byte index to
cell index, the rendered had to be updated to dirty one extra cell
from the original grid.
Without this, we left trailing cursors behind us when the user deleted
text from the pre-edit string.
When rendering the search input box, do the same ad-hoc workaround for
combining characters with a positive x-offset as we do when rendering
normal grid cells.
In this case, we don’t *know* when we’re dealing with combining
characters. But we can detect zero-width characters. For these, check
their glyph’s x-offset. If positive, adjust it like we do when
rendering combining glyphs in the main grid, to ensure the glyph is
positioned over the _previous_ character, not the next.
These two buttons were encoded using the *exact* same numbers as
button 4 and 5 (scroll wheel up/down), making it impossible to
distinguish them.
The relevant section from XTerm’s control sequences documentation is:
Some wheel mice can send additional button events, e.g., by tilting the
scroll wheel left and right.
Additional buttons are encoded like the wheel mice,
o by adding 64 (for buttons 6 and 7), or
o by adding 128 (for buttons 8 through 11).
