To determine the logical key that was pressed, we previously just
trusted that the translated text would have the right value. But if
modifiers are pressed, the text may not translate.
For example on macOS, Ctrl+C does not produce any text. As a result, we
would fall back to the physical key. On layouts like Dvorak, the
physical key for "C" is "I". This means "Ctrl+C" sequences weren't
working.
Instead, if there is no text or the text doesn't map to a key, we
translate again using no modifiers to try to get the raw text of the
input and then base the key on that.
See:
https://github.com/mitchellh/ghostty/issues/242#issuecomment-1678268533
Quoted:
@hovsater OKAY! I've consulted _the source_, i.e. `xterm`. None of the other reference material was illuminating and there is so much conflicting implementation out there and so very few terminals actually support `modifyOtherKeys`. I believe I've figured it out.
I believe that `C-S-h` is only supported via `modifyOtherKeys` state 2. iTerm emits it for state 1 but I think this is a mistake and I can't get any other terminal to do it, including `xterm`.
Here is my test script on Linux:
```
printf "\x1b[>4;1m" # change to "2" for state 2
showkey -a
```
With state 1, I couldn't get any terminal to output anything for `C-S-h`. **But with state 2, xterm outputs: ** `CSI 27;6;72~`. One thing to note is 72 is `H` (uppercase), so in even this case, iTerm appears to be sending the wrong code or `dte -K` is outputting the wrong case (less likely I think).
When I launch `dte` (the full editor), it only requests `modifyOtherKeys` state 1. So, with only `modifyOtherKeys` support, it shouldn't get access to `C-S-h`.
Note that I couldn't get any terminal on macOS to show the same sequences as xterm under any circumstance. I also cracked open the `xterm` source and I only eyeballed it but I believe this is not sending the sequences under state 1: https://sourcegraph.com/github.com/ThomasDickey/xterm-snapshots@c2b36af8d216926b8931c6f9cebefd69228e437c/-/blob/input.c?L579
**I could be very wrong, I'm not confident.** Every implementation (and there are only few) seems different and the behaviors are not consistent at all. Hence, I'm falling back to `xterm`, but even then I could be reading the source wrong. But when I ran `xterm` manually I could only get `C-S-h` to show up in state 2.
Fontconfig in particular appears unsafe to initialize multiple times.
Font discovery is a singleton object in an application and only ever
accessed from the main thread so we can work around this by only
initializing and caching the font discovery mechanism exactly once on
the app singleton.
Fixes#267
We have a mechanism `ignore_char` to ignore the `charCallback` exactly
once. It is guaranteed by all app runtimes that `keyCallback` is called
before `charCallback` and that they're called in order by key press
(you'll never get 3 `keyCallbacks` and then `charCallback` for the first
press).
We use this for example to ensure that if you bind `a` to something,
that we never actually print 'a', since the binding consumes it.
This commit sets `ignore_char` whenever we detect a key that should be
translated to a control character and written to the pty. As the comment
in the code states: we probably should've been doing this anyways. It is
a complete mystery why macOS behaves the way it does that caused us to
figure this out.
Fixes#256
This makes a whole lot more sequences work, such as `ctrl+left`,
`ctrl+shift+f1`, etc. We were just missing these completely.
This also found an issue where if you split a sequence across two
`write()` syscalls, then `/bin/sh` (I didn't test other shells)
treats it as two literals rather than parsing as a single sequence.
Great.
This reverts commit c139279d479682c17f63d9b57c2d56608d09d16a, reversing
changes made to 4ed21047a734d7c586debe0026e3b6ea90ed1622.
We do want to do this but this broke bindings.
Previously, we'd send renderer screen size updates and termio sigwnch
updates on every single resize event even if the screen size or grid
sizes didn't change. This is super noisy and given how many resize
events macOS sends, its also very expensive.
This commit makes it so that we only update the renderer if the screen
changed. If the screen size didn't change, the grid size couldn't have
changed either.
If the screen size did change, its still possible the grid size didn't
change since Ghostty supports fluid pixel-level resizing. We have to
send the screen size event to the renderer so all the GPU shader vars
are right but we do not have to send a termio event.
So, only if the grid size changed do we then notify the pty that the
terminal dimensions changed. Note that the resize event for ptys does
have a pixel-level x/y but I don't think the granularity is useful
beyond grid changes.
This fixes#99 for me.
Without this fix I end up with paddings of `3.333333` because my DPI is
`125.0` on Linux. If I set it to `144.0` manually so that the `/ 72`
gives me a clean `2.0`, the blurry fonts are gone.
I do think the calculation here is correct (even though I'm not sure
whether we should use 72? Why not 96? Or another system value?), so
let's use `std.math.floor` to get us to a "clean" padding of `3.0`.
That also solves blurry fonts for me.
Font metrics realistically should be integral. Cell widths, cell
heights, etc. do not make sense to be floats, since our grid is
integral. There is no such thing as a "half cell" (or any point).
The reason we historically had these all as f32 is simplicity mixed
with history. OpenGL APIs and shaders all use f32 for their values, we
originally only supported OpenGL, and all the font rendering used to be
directly in the renderer code (like... a year+ ago).
When we refactored the font metrics calculation to its own system and
also added additional renderers like Metal (which use f64, not f32), we
never updated anything. We just kept metrics as f32 and casted
everywhere.
With CoreText and #177 this finally reared its ugly head. By forgetting
a simple rounding on cell metric calculation, our integral renderers
(sprite fonts) were off by 1 pixel compared to the GPU renderers.
Insidious.
Let's represent font metrics with the types that actually make sense: a
cell width/height, etc. is _integral_. When we get to the GPU, we now
cast to floats. We also cast to floats whenever we're doing more precise
math (i.e. mouse offset calculation). In this case, we're only
converting to floats from a integral type which is going to be much
safer and less prone to uncertain rounding than converting to an int
from a float type.
Fixes#177
This fixes or at least is the first step towards #171:
- it adds `cmd/super + return` as the default keybinding to toggle
fullscreen for currently focused window.
- it adds a keybinding handler to the embedded apprt and then changes
the macOS app to handle the keybinding by toggling currently focused
window.
