Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS: Option + Left / Right key handling #5793

Closed
HealsCodes opened this issue Dec 18, 2022 · 8 comments
Closed

macOS: Option + Left / Right key handling #5793

HealsCodes opened this issue Dec 18, 2022 · 8 comments

Comments

@HealsCodes
Copy link

HealsCodes commented Dec 18, 2022

Is your feature request related to a problem? Please describe.
It is indeed, and I am probably just not smart enough to figure out how to get this working in kitty.
The default macOS Terminal.app supports pressing Option + Left / Right to move the cursor by one word.
This is really useful for command line editing but when I try the same in kitty I get a <ESC>[1;3D and <ESC>[1;3C inserted instead.

Describe the solution you'd like

Ideally these word moves should work out-of-the-box on platforms that support it (e.g. macOS).
I am however aware that this doesn't only depend on the terminal but also on the shell running inside it.

Describe alternatives you've considered

I have a working alternative right now, however I'm not entirely sure how portable this is and why it works in the normal terminal app without.
Adding this to to a user's .zshrc will "fix" the behoviour:

bindkey "\e[1;3C" emacs-forward-word
bindkey "\e[1;3D" emacs-backward-word

Additional context

Kitty already seems to be aware of the "moveWord*" requests it receives from the NSEvent context:

---------------- key down -------------------
NSEvent: type=KeyDown loc=(124.945,474.281) time=2245.6 flags=0xa80120 win=0x123627e80 winNum=426 ctxt=0x0 chars="" unmodchars="" repeat=0 keyCode=123
Press: native_key: 0x7b (<cc>) glfw_key: 0xe006 mods: alt char_count: 1 deadKeyState: 0 repeat: 0 
	TextInputCtx: doCommandBySelector: (moveWordLeft:)
text: <none> glfw_key: LEFT marked_text: ()
on_key_input: glfw key: 0xe006 native_code: 0x7b action: PRESS mods: alt text: '' state: 0 updateIMEPosition: left=113.500000, top=4.500000, width=7.000000, height=18.000000
sent encoded key to child
---------------------------------------------
@kovidgoyal
Copy link
Owner

https://sw.kovidgoyal.net/kitty/faq/#how-do-i-map-key-presses-in-kitty-to-different-keys-in-the-terminal-program

As for out of the box I am not really comfortable with doing that.
shells have their own config for this, and shoehorning another platforms
conventions on top of them be default doesn't feel right.

That said I am not completely averse to it, it would at the very least
mean I dont have to periodically answer this question :)

@page-down
Copy link
Contributor

@kovidgoyal
I don't think more send_text should be added to the default configuration than is necessary, even for the so-called "out-of-the-box experience".

  • As I tested, in the latest bash, fish, Option+Left/Right will move the cursor by word, out of box. zsh will be the only one of these three shells that does not have this action (key escape sequence) configured by default.
  • These two default configurations will directly cause bindkey "\e[1;3C" whatever-widget ... to be unusable unless the user has already configured clear_all_shortcuts yes.
  • Mimicking a particular terminal of a particular platform (just for a certain shell) should not be the goal of kitty. (Although the intention is to lower the barriers and enhance the experience.)

As far as I know, there has been feedback from users that certain keys don't respond in the program (e.g. Neovim, Ctrl+Shift+6), which is why I think unnecessary default shortcut configurations should be minimized.

If this is the final decision, then I think it will annoy some of the users who are already using kitty, and two more map ... no_op need to be added to the configuration.

... I dont have to periodically answer this question ...

I think it's acceptable to put this configuration suggestion in the FAQ (although not very often, so far), and I remember where in the documentation there are already some configuration suggestions for zsh.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Dec 19, 2022 via email

@HealsCodes
Copy link
Author

HealsCodes commented Dec 19, 2022

I tested with bash and fish on macOS and neither of them reacts to the keys without extra configuration (if run inside kitty).

@kovidgoyal
Copy link
Owner

Guys, can we get a comprehensive answer on this. Please run bash and
fish with default configurations and up-to-date versions (in particular
this means not using Apple's bundled bash) and see. Post whatever
versions of the shells you are running. It should be fairly simple to
add mappings for these to the bash and fish integration scripts as well,
if needed.

@HealsCodes
Copy link
Author

Guys, can we get a comprehensive answer on this. Please run bash and
fish with default configurations and up-to-date versions (in particular
this means not using Apple's bundled bash) and see. Post whatever
versions of the shells you are running. It should be fairly simple to
add mappings for these to the bash and fish integration scripts as well,
if needed.

Revert the changes you added.. if people wanna be picky let them.

It works with a 5.2 bash release which will very likely never appear on any macOS sytem as Apple has declared bash to no longer be a supported shell in favour of zsh and is only shipping a 3.x release for compatibility with scripts.
Most macOS users won't go as far as installing or updating to latest-release versions of either bash or fish as it breaks all kinds of things in the system.

I'm of the opinion that behaving as the user on a certain platform expects instead of being an agnostic canary or requiring the user to manually install newer system shells is the better experience but apparently there's people with strong views on this and all I asked for was a pointer in the right direction which I found myself.

@page-down
Copy link
Contributor

I tested with bash and fish on macOS and neither of them ...

I tested the latest bash and fish, and checked bind for the default keys.

bash 5.2.15:
"\e[1;3C": forward-word
"\e[1;3D": backward-word

fish 3.5.1:
bind --preset \eO3C nextd-or-forward-word
bind --preset \eO3D prevd-or-backward-word
bind --preset \e\[3C nextd-or-forward-word
bind --preset \e\[3D prevd-or-backward-word
bind --preset \e\[1\;3C nextd-or-forward-word
bind --preset \e\[1\;3D prevd-or-backward-word

It should be fairly simple to add mappings for these to the bash and fish integration scripts as well, if needed.

@kovidgoyal
I believe bash integration will not work in lower versions like 3.x.
For fish there is no need to worry, at least in the year 2007 these keys are already supported.

... if people wanna be picky ...

The biggest issue with the previous implementation was that under macOS it would not be possible to distinguish between Option+Left/Right and Alt+B/F by default.
And I think this conflicts with the design philosophy of kitty (and the kitty keyboard protocol, although the previous implementation has nothing to do with it).

I am not against this improvement, as long as the design concept of kitty is consistent, it is acceptable to me.

It works with a ... bash release which will very likely never appear ...
... users won't go as far as installing or updating ... as it breaks all kinds of things ...

Users who use the latest version of the software should not be penalized.
Also, it is perfectly fine to install the latest version, but not put it in the system's default PATH and configure the shell and PATH in kitty to avoid "breaks all kinds of things".

I'm of the opinion that behaving as the user on a certain platform expects ...

I must say that my opinion is the same. This will make for a better out-of-the-box experience and make it easy for users to get started. If kitty is designed to cover these types of target users.

@kovidgoyal
Copy link
Owner

Eh this issue is done and dusted. The keys are not mapped in kitty.conf
anymore. They are mapped only in the zsh shell integration and then only if they were
previously unmapped. I dont care about Apple's obsolete bash, if people
want to use it, they get to own all the problems it will create.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants