Issues with macOS option key

[dvorakluk]

I guess it's a combination of macOS, the Apple keyboard and my keyboard layout. I'm used to using Czech layout even for programming without switching layouts - thanks to the Option key. But from my limited understanding it seems that flow is registering Option key as an Alt modifier?

for example running flow --show-input in helix INS mode and trying to write > via right ⌥ + .
I see A-> is unbound, press C-? for key hints in the status bar and following input sequence

  1466▎["I",1,57449,57449,"",2] -> press:right_alt
   261▎["I",1,46,46,">",2] -> press:alt+>
    92▎["I",3,46,46,"",2] -> release:alt+.
   160▎["I",3,57449,57449,"",0] -> release:right_alt

Same sequence produces > in fish, helix and vim

The same behaviour can be observed for all characters accessed via the Option key, > being just one example.

terminal: Ghostty 1.2.3 (with macos-option-as-alt = left, but tried disabling)
flow version: v0.6.0-243-g090d27d

am I overlooking some config?

[neurocyte]

This is a macos oddity that has been discussed a few times, in Ghostty and Kitty issues. There doesn't seem to be a clear solution afaik.

I just came across this though: ghostty-org/ghostty#9406

Maybe you could give that version of Ghostty a try and see if the alt modifier issue is fixed for you.

Here is the thread that lead up to the fix: ghostty-org/ghostty#8893

[danielwe]

If the terminal application can differentiate regular alt modified events from macos option-as-alt modified events

Kovid is right that you can't know that option was consumed from information contained in the key event itself. Ghostty just assumes that macOS input handling will consume all modifiers except control and command. macos-option-as-alt works by intercepting the event before translation to remove option from the set of modifiers and thus prevent the OS from consuming it, and then adding it back to the modifier set of the translated event.

Kovid seems quite insistent on not engaging in such guesswork for the Kitty protocol. He has also criticized xterm modifyOtherKeys and doesn't support it in Kitty, so he has no need for ghostty-org/ghostty#9406.

Is your goal to eventually persuade Kovid to change his mind, or is it not a goal for flow work correctly in Kitty? In either case, it's probably a good idea to point out in ghostty-org/ghostty#9816 that it's a deviation from how Kitty currently implements the protocol.

[neurocyte]

Is your goal to eventually persuade Kovid to change his mind, or is it not a goal for flow work correctly in Kitty?

I have no particular goal here besides making a couple of macos users happy. Kovid has stated that he is not willing to put macos specific input handling workarounds in kitty. That is a perfectly fine stance to take and flow works just fine with kitty on macos. I've also stated that I'm not willing to put macos specific workarounds (ignoring alt modifiers on alternate input) in flow, so Kovid and I are pretty much on the same page.

In either case, it's probably a good idea to point out in ghostty-org/ghostty#9816 that it's a deviation from how Kitty currently implements the protocol.

The kitty keyboard protocol spec does not make any claims or demands on how OS key events must be mapped terminal events. How could it? There are literally a thousand variations on what that might mean. Doing this mapping slightly differently is not a "deviation" from the protocol.

Ghostty is a much more macos focused project than kitty, so I think it is likely that they would want this mapping to follow macos user expectations more closely, even if that means macos specific workarounds. That is why I suggested they use the same workaround that you made for other input modes for kitty mode too.

[danielwe]

I've also stated that I'm not willing to put macos specific workarounds

The suggested way to deal with this per Kovid is not an OS-specific workaround, it's to unconditionally consider every key event with associated text as a text input event (at least when the program is in a state where it can accept text input).

flow works just fine with kitty on macos

If this is an issue with Ghostty it's an issue with Kitty too? They currently produce the same codes for this class of key events on macOS.

Doing this mapping slightly differently is not a "deviation" from the protocol.

This may depend on who you ask, that's why I said "deviation from how Kitty currently implements the protocol." I'm not arguing for or against the change, just trying to make sure we're all clear that it's a deliberate choice to diverge from Kitty in a way that is observable and may cause programs to behave differently.

[neurocyte]

The suggested way to deal with this per Kovid is not an OS-specific workaround, but considering every key event with associated text as a text input event (at least when the program is in a state where it can accept text input).

That will prevent you from binding many keys on international keyboards across all OSes, which is not an acceptable workarouund for a macos specific issue.

flow works just fine with kitty on macos

If this is an issue with Ghostty it's an issue with Kitty too? They currently produce the same codes for this class of key events.

It works in the sense that users get the original OS events and can bind them as they see fit. It's not what users expect though. And yes, this is currently the same for Kitty and Ghostty.

[danielwe]

That will prevent you from binding many keys on international keyboards across all OSes

I'm still not sure I understand what concrete examples you have in mind here. In the other discussion you said "We are talking here about key events that contain an alt modifier, but are not actually alt modified", but that's exactly what associated text resolves. If it were actually alt modified, there wouldn't be associated text. The fact that there is associated text means it isn't actually alt modified.

The option/alt overloading limits what you can express on macOS (alt+<character typed using option> is off the table if you want to be able to type <character typed using option>), but I don't see what the limitations would be on other OSs that don't have this overloading? Specifically, AltGr isn't encoded as a modifier in the protocol at all, it only affects the unicode-key-code and associated text fields, so there's nothing to conflate there. (kovidgoyal/kitty#8126 (comment))

Of course, if you allow the user to bind actions to events that would otherwise produce text (maximally trivial example: binding shift+a to an action even in insert mode, such that it will no longer insert "A"), such bindings will continue to be exceptions to the rule that associated text always inserts text. But surely such events must fall back to inserting the text if they're not actually bound? The suggestion is just to extend this fallback path to every event that has associated text, regardless of modifiers.

In short: If the event has associated text, and is otherwise unbound according to the various heuristics for matching key bindings, treat it as text input. What does this rule prevent me from doing, with any keyboard layout, that I would be able to do if an alt in the modifier set meant that associated text would be discarded?

[neurocyte]

If it were actually alt modified, there wouldn't be associated text. The fact that there is associated text means it isn't actually alt modified.

Well this is the point isn't it. Why send modifiers along with associated text if they must be disregarded entirely? (A "rule" that is not even implied in the spec btw)

In short: If the event has associated text, and is otherwise unbound according to the various heuristics for matching key bindings, treat it as text input.

If modifiers on events with associated text must be ignored then there are no other heuristics are there?

[neurocyte]

I think we're talking past each other. Let me try to explain myself again.

I understand your point and Kovid's stance entirely. There is no need to explain it again. Apparently it is not clear why I am saying it is not acceptable, so I'll state it using the example above that started the discussion.

When the user enters > on their keyboard (using option on a mac) the following event is generated:

Event: keypress
Symbol: >
Modifiers: alt
Alternate input text: >

Now two things can happen in flow.

1. We match a keybind on alt+> and execute a command

2. We see there is alternate text and input > into the document, ignoring the modifier

So which is the correct option? The correct answer is neither, because both will at some point violate user expectations.

1. Is always wrong, because there may be some user somewhere that has a macos keyboard with > modified by the option key. If we execute a command, they lose the ability to input >. Note: As far as I can tell, this is an open set of keys. This is what I am trying to get fixed in Ghossty and Kitty.

2. This may be wrong, because the user may have actually pressed a modifier and does not expect anything to be input. This depends on the OS event info (example macos).

Kovid understands that this is ambiguous and says it is at the OS level and cannot be disambiguated in kitty due to lack of OS reported information.

I understand that this is ambiguous and say it cannot be generally disambiguated at the application level, because there is no one-size-fits-all solution.

Don't get hung up on whether 2. is possiblly wrong or not. 1. is catastrophic already, even if 2. is not an issue.

[danielwe]

Event: keypress
Symbol: >
Modifiers: alt
Alternate input text: >

According to OP it's "Symbol: .". The fact that the associated text is different from both the symbol key and (if present) shifted key is an extra piece of information that you probably need to use to get reasonable behavior. See footnote above, though an alternative rule could be to just completely skip keybind matching when this is the case, which would eliminate the concern about the catastrophic option 1.

[neurocyte]

See footnote above

Footnote 1 above exactly matches flow's current behavour.

though an alternative rule could be to just completely skip keybind matching when this is the case, which would eliminate the concern about the catastrophic option 1.

And effectively ignore all modifiers in this specific case?

This may be a useable workaround for the alt modifier issue on macos. I will see if I can add an option to flow for users to experiment.

It still begs the question though, if this heuristic is generally applicable, why send the modifiers at all? And why force every KKP app to implement this very specific and fairly arbitrary rule client side instead of just removing the known-to-be-meaningless modifier in the terminal app?

[danielwe]

if this heuristic is generally applicable, why send the modifiers at all?

I mean I agree. If it were up to me, option would be like AltGr, i.e., never encoded. I think the discussions we've had are pretty good evidence that the "option is encoded as alt even if macos-option-as-alt = false" thing was never a good idea. My only contention has been that as long as Kitty won't change, I don't think it would improve anything if terminals started to diverge, and I do think apps can make the best of what we have without compromising functionality on non-macOS systems.

Footnote 1 above exactly matches flow's current behavour.

I thought the problem was that it doesn't fall back to inserting the text in the absence of a matching key binding? Isn't that what the OPs struggle with both here and in ghostty-org/ghostty#9511?

[neurocyte]

I though the problem was it doesn't fall back to inserting the text in the absence of a matching key binding?

Well, footnote 1 is almost exactly flow's behavior. It does finally fallback to insert, but only if there were no (non-shift) modifiers on the event.

[neurocyte]

There is a keybind_mode option ignore_alt_text_modifiers that can enable the workaround suggested by @danielwe.