search

gnotclub / xst

st fork that uses Xresources and some pretty good patches
MIT License
536 stars 74 forks source link

Add more shortcuts #146

Open RaafatTurki opened 2 years ago

RaafatTurki commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I see, you must be talking about https://github.com/kovidgoyal/kitty/issues/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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

neeasade commented 2 years ago

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: https://github.com/gnotclub/xst/blob/293b895061ac52ceb8eeef15d6447a917cf5ccd9/xst.c#L27. Handling would need to be added there to reset the keymapping somehow