-
Notifications
You must be signed in to change notification settings - Fork 74
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 more shortcuts #146
Comments
This project is only concerned with upstream compat re: terminal keypress protocols. Aside from that, the only one I'm interested in is kitty's protocol. I would love it st becomes compatible with the kitty protocol or a patch were to surface for that, but would recommend just using kitty itself. The linked PR I had /could work/ as a shim for the linked patch, but the intent was for application level presses, not sending term-keys |
I see, you must be talking about this.
How realistic do you recon implementing this would be |
correct
not realistic -- I've seen it discussed upstream on occasion, but I do not think they are interested in incorporating it |
regarding original proposal: if there is some elegant way to implement it as an optional behavior - then i think why not, we could merge it? |
If there's no merge block I'd take a stab at it. |
mb wait for @neeasade if he also dont mind this, as i'm not sure from his replies above |
I'm rather not interested in this, both for the caveats listed in the st patch page and the fixterms tradeoffs mentioned at the bottom of the kitty protocol documentation: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#fixterms-bugs Having a PR for reference is always welcome though
re what "elegant" means to xst, it means small/isolated diffs where possible, to ease future merges with upstream st
The USR1 signal calls this function: . Handling would need to be added there to reset the keymapping somehow |
As you know terminals can't really understand every keypress due to historical limitations.
However modern terminals (kitty, Alacritty, iTerm2 .. etc) don't abide by that and use the full range of keyboard shortcuts. more about this topic here
An st patch has already been cooked for this a while back and it only edits
config.def.h
The catch is making it user configurable (opt-in preferably). As I'm sure not all users want all the new bindings.
for example currently
Ctrl [
is interpreted asEsc
and I'm sure some users have that mapping ingrained into their muscle memory.An another thing is this PR @neeasade was working on. idk if it's abandoned or if it would make this patch obsolete?
The text was updated successfully, but these errors were encountered: