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 more shortcuts #146

Open
RaafatTurki opened this issue Apr 27, 2022 · 7 comments
Open

Add more shortcuts #146

RaafatTurki opened this issue Apr 27, 2022 · 7 comments

Comments

@RaafatTurki
Copy link
Contributor

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 as Esc 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?

@neeasade
Copy link
Member

neeasade commented May 5, 2022

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

@RaafatTurki
Copy link
Contributor Author

I see, you must be talking about this.

or a patch were to surface for that

How realistic do you recon implementing this would be

@neeasade
Copy link
Member

I see, you must be talking about kovidgoyal/kitty#3248.

correct

How realistic do you recon implementing this would be

not realistic -- I've seen it discussed upstream on occasion, but I do not think they are interested in incorporating it

@actionless
Copy link
Collaborator

actionless commented Jun 25, 2022

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?

@RaafatTurki
Copy link
Contributor Author

RaafatTurki commented Jun 26, 2022

If there's no merge block I'd take a stab at it.
I'll need someone to show me an example of how to make it xrdb configurable since we can't just patch config.def.h and call it a day.

@actionless
Copy link
Collaborator

mb wait for @neeasade if he also dont mind this, as i'm not sure from his replies above

@neeasade
Copy link
Member

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

if there is some elegant way to implement it as an optional behavior

re what "elegant" means to xst, it means small/isolated diffs where possible, to ease future merges with upstream st

I'll need someone to show me an example of how to make it xrdb configurable since we can't just patch config.def.h and call it a day.

The USR1 signal calls this function:

xst/xst.c

Line 27 in 293b895

xrdb_load(void)
. Handling would need to be added there to reset the keymapping somehow

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

No branches or pull requests

3 participants