Currently, the selection on a surface is cleared on any keypress that
generates a control sequence. For applications that enable kitty, this
can mean that every keypress clears the current selection thereby making
it impossible to copy text, since it will be cleared as soon as Control
is pressed. This can be very confusing to terminal users: some
applications I can shift+highlight and copy+paste, some I can't - and
unless I know the implementation of the application I won't know
why...very frustrating.
Only clear the selection when there is printable text, otherwise retain
the selection. From my testing, this makes text selection feel the same
between applications using kitty keyboard and applications that don't.
The macOS desktop menu-bar grows in total height by adding extra padding
to deal with the physical notch found on various MacBook displays.
When config `macos-non-native-fullscreen = visible-menu` we apply
`safeAreaInsets.top` to reduce frame height.
User input withe Alt modifier is typically ESC prefixed. Escape
prefixing a non-ascii character can cause bugs in some applications. For
example in bash, emitting an Alt+ф allows the user to backspace one
character into the prompt. This can be repeated multiple times.
When a character is outside the ASCII range (exclusive of 0x7F, this is
handled as a control sequence), print the character as is, with no
prefix.
Fix reporting of alternate keys when using the kitty protocol. Alternate
keyboard layouts were failing to report the "base layout" key. This
implementation now matches kitty's output 1:1, and has some added unit
tests for cyrillic characters.
This also fixes a bug where a caps_lock modified key would report the
shifted key as well. The protocol explicitly requires that shifted keys
are only reported if the shift modifier is true.
When converting keyval to the unshifted version, gdk_keyval_to_lower
returns a keyval type, not a unicode value. Convert this to unicode
before assigning to keyval_unicode_unshifted.
This fixes a bug where the incorrect keycode is sent in alternate
layouts with kitty keyboard on linux.
Fixes#315
This function has various cases that can be hit depending on the state
of the underlying circular buffer. It is a very well tested function but
this particular branch wasn't tested and unsurprisingly turns out there
is a bug in it.
Consider the following circular buffer state representing a terminal
screen with 1 column, 5 rows. Assume the circular buffer representing
this screen is such that `head == tail` and `head = 4` (zero-indexed,
full buffer size is 5). The head and tail are shown with an arrow below.
┌───────────────────────────────────────────────────────────────┐
│ B │
├───────────────────────────────────────────────────────────────┤
│ C │
├───────────────────────────────────────────────────────────────┤
│ D │
├───────────────────────────────────────────────────────────────┤
│ E │
├───────────────────────────────────────────────────────────────┤ ◀─── Head
│ A │ Tail
└───────────────────────────────────────────────────────────────┘
The screen contents are "A B C D E" with each character on a new line.
Next, we set a scroll region from y=0 to y=3 (len=4). The scroll region
contents are "A B C D". Next, we issue a "delete lines" command with
n=2 (`CSI 2 M`) while the cursor is at the top-left corner. The delete
lines command deletes the given number of lines (n=2 in this case) and
shifts the remaining lines up. It does this only within the context
of the scroll region. Therefore, for `CSI 2 M` we would expect our
screen to become "C D _ _ E" (A, B are deleted, C, D shift up, and
E is untouched because its outside of the scroll region).
When executing this operation, we request the memory regions containing
the scroll region. This results in two pointers and lengths. For our
circular buffer state, we get the following:
┌───────────────────────────────────────────────────────────────┐ ◀──── ptr0
│ A │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐ ◀──── ptr1
│ B │
├───────────────────────────────────────────────────────────────┤
│ C │
├───────────────────────────────────────────────────────────────┤
│ D │
└───────────────────────────────────────────────────────────────┘
We get two pointers because our circular buffer wraps around the bottom.
The diagram above shows them in top/bottom order not in memory order
(The value of `ptr0 > ptr1` but it doesn't matter for the bug).
The way the math works is as follows:
1. We calculate the number of lines we need to shift up. That
value is `height - n`. Our height is 4 (scroll region height) and
our n is 2 (`CSI 2 M`), so we know we're shifting up 2 lines.
Let's call this `shift_lines`.
2. Our start copy offset is `n` because the lines we are retaining
are exactly after the `n` we're deleting (i.e. we're deleting 2
lines so the start of the lines we're shifting up is the 3rd line).
Let's call this `start_offset`.
3. We realize that our start offset is greater than the size of ptr0,
so we must be copy from ptr1 into ptr0. Further, we know our start
offset into ptr1 must be `start_offset - ptr0.len`.
Let's call this `start_offset_ptr1 = 1`.
4. Copy `ptr1[start_offset_ptr1]` to `ptr0`. We copy up to
`shift_lines` amount. `shift_lines` is 2 but `ptr0.len` is only
`1`. So, we actually copy `@min(shift_lines, ptr0.len)` and have
`1` line remaining.
Let's call that `remaining = 1`.
5. Copy `remaining` from `ptr1[ptr0.len]` to `ptr1`.
6. Next we need to zero our remaining lines. Our slices only contain
our scroll region so we know we can zero the memory from
`ptr1[remaining]` to the end of `ptr1`. We know this because step 5
only copied `remaining` bytes.
The end result looks like this:
┌───────────────────────────────────────────────────────────────┐ ◀──── ptr[0]
│ C │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐ ◀──── ptr[1]
│ D │
├───────────────────────────────────────────────────────────────┤
│ │
├───────────────────────────────────────────────────────────────┤
│ │
└───────────────────────────────────────────────────────────────┘
The bug was in step 6. We were incorrectly zeroing from `start_offset_ptr1`
instead of `remaining`. This was just a simple typo. The results are
devastating, but only under the exactly correct circumstances (those
in this commit message). In that scenario, the bug produced the
following:
┌───────────────────────────────────────────────────────────────┐ ◀────────── ptr[0]
│ C │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐ ◀────────── ptr[1]
│ D │
├───────────────────────────────────────────────────────────────┤
│ C │
├───────────────────────────────────────────────────────────────┤
│ │
└───────────────────────────────────────────────────────────────┘
Notice the incorrect "C" that remains and is not zeroed.
This example showed a scenario with 1 column and leaving only 1 line out
of the scroll region. The real bug in #315 would often mistakingly leave
multiple lines in the scroll region. The effect was that scrolling
produced garbage lines because you'd "scroll" and part of what should've
scrolled would remain.
This garbage state was only in the terminal screen state, so it didn't
impact actual programs running or their data (i.e. vim). But, it made
the program unusable.
