If GTK reports a negative or zero scale, we ignore that and use 1.0 for the scale. Backport of #5954
If GTK reports a negative or zero scale, we ignore that and use 1.0 for the scale. Backport of #5954
Fixes #6821 UTF8 translation using KeymapDarwin requires a buffer and the buffer was stack allocated in the coreKeyEvent call and returned from the function. We need the buffer to live longer than this. Long term, we're removing KeymapDarwin (there is a whole TODO comment in there about how to do it), but this fixes a real problem today.
Fixes #6772 When typing Korean with the fcitx5-hangful input method, moving between graphemes does not trigger a preedit end/start cycle and instead just clears the preexisting preedit and reuses the started state. Every other input method we've tested up until now doesn't do this. We need to mark composing set to "false" in "commit" because some input methods on the contrary fail to ever call END. What is the point of start/end events if they are just ignored depending on the whim of the input method? Nothing. That's what. Its all a mess that GTK should be protecting us from but it doesn't and now its the app developer's problem. I'm frustrated because I feel like the point of an app framework is to mask this kind of complexity from the app developer and I'm playing whack-a-mole with input methods. Well, here's another whack. Let's see if it works.
This was causing garbled text due to a non-rebuilt rows referencing an outdated atlas when the DPI changed but not the grid dimensions, which could be caused by a variety of things such as the quick terminal slide-in, dpi scaling changes on sleep/wake, moving windows between displays because of closing/opening the laptop lid, etc.
See #5930 Kakoune sends a real SGR sequence with 17 parameters. Our previous max was 16 so we through away the entire sequence. This commit increases the max rather than fundamentally addressing limitations. Practically, it took us this long to witness a real world sequence that exceeded our previous limit. We may need to revisit this in the future, but this is an easy fix for now. In the future, as the comment states in this diff, we should probably look into a rare slow path where we heap allocate to accept up to some larger size (but still would need a cap to avoid DoS). For now, increasing to 24 slightly increases our memory usage but shouldn't result in any real world issues.
In Termio.init, we make a copy of backend and modify it by calling initTerminal. However, we used the original in the struct definition. This lead to the pty being opened with a size 0,0.
The Ghostty implementation of OSC 21 (Kitty color protocol) currently responds to *all* OSC 21 sequences. It should not respond to a set, nor a reset command. Fix the implementation so that we only respond if a query was received.