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

Add key commands for moving per word #289

Closed
wants to merge 1 commit into from
Closed

Add key commands for moving per word #289

wants to merge 1 commit into from

Conversation

kronawetter
Copy link

This maps Option + Right Arrow to move forward-word and Option + Left Arrow to move backward-word, like in the default key mapping of the macOS Terminal app.

I decided to create separate methods instead of extending handleKeyCommand: as this is not standard behavior of a shell. (similar to the existing Command + K key command for clearing the screen) If it is preferred to extend handleKeyCommand:, I am happy to update this PR accordingly.

This maps Option + Right Arrow to move forward-word and Option + Left Arrow to move backward-word, like in the default key mapping of the macOS Terminal app.
@tbodt
Copy link
Member

tbodt commented Jan 26, 2019

Thanks! The problem with this approach is that in a lot of programs \x1bb and \x1bf don't move between words. iTerm uses \x1b\x1b[C and \x1b\x1b[D which works in some programs but breaks in others, and lets you configure it in the settings. I'm thinking option should work as a modifier to send escape before whatever key you pressed, so then if all else fails option-b and option-f would work.

@kronawetter
Copy link
Author

After submitting this PR, I started to realize that there might be some compatibility issues with these hard-coded sequences. I personally only move per words in the bash, where this sequence works just fine.

While I understand that using the Option key as Meta is a feature provided in most terminal applications, I do not like to use this setting as on non-English keyboards the Option key has to be used quite frequently.

Therefore, I tend to implement user-customizable key mappings. Does it currently make sense to do so or do you plan to introduce any changes soon that might require a rework of this functionality?

@tbodt
Copy link
Member

tbodt commented Jan 26, 2019

User-customizable key mappings would be awesome! And even if I was going to replace the terminal emulator tomorrow, the keyboard handling code would probably stay the same, so go right ahead.

@kronawetter
Copy link
Author

kronawetter commented Jan 26, 2019

So, I’d like to keep this simple for now and similar to the functionality provided by the stock Terminal app on macOS.

Proposed differences from the Terminal app:

Would you be okay with these features?

Screenshots of macOS Terminal app, for reference:
screen shot 2019-01-26 at 23 48 50
screen shot 2019-01-26 at 23 41 54
screen shot 2019-01-26 at 23 41 59

@tbodt
Copy link
Member

tbodt commented Jan 26, 2019

Looks good for a first version. Of course it would also be nice to include that "use option as meta key" checkbox, if that wouldn't be too hard.

@tbodt
Copy link
Member

tbodt commented Oct 26, 2019

Closing as we now have option->meta mappings, which fulfills the original purpose of this PR.

@tbodt tbodt closed this Oct 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants