Hi!

I noticed that my <C-h> keybinds stopped working after upgrading to
0.18.0. I've read through the changelog and it didn't look like an
intended deprecation.

I believe it is an issue with the new version and not my terminal
capturing <C-h>, since I tried downgrading to 0.17.0, and the <C-h>
worked again.

I've tried mapping other commands to <C-h> and none of them worked.
The log I got from aerc > aerc.log shows that the mapped commands never
got triggered so I believe it is an issue with capturing the keybinds.

Coco

On Mon Jul 15, 2024 at 03:04, Coco Liliace <coco@liliace.dev> wrote:
> Hi!
>
> I noticed that my <C-h> keybinds stopped working after upgrading to
> 0.18.0. I've read through the changelog and it didn't look like an
> intended deprecation.

I can repro this in gnome-terminal, but not on ghostty or contour. I suspect it
might have to do with the kitty keyboard protocol?

I've CC-d Tim as this is probably a vaxis related issue.

Best,
Bence


-- 
+36305425054
bence.ferdinandy.com

On Sun Jul 14, 2024 at 8:05 PM CDT, Coco Liliace wrote:
> Hi!
>
> I noticed that my <C-h> keybinds stopped working after upgrading to
> 0.18.0. I've read through the changelog and it didn't look like an
> intended deprecation.
>
> I believe it is an issue with the new version and not my terminal
> capturing <C-h>, since I tried downgrading to 0.17.0, and the <C-h>
> worked again.
>
> I've tried mapping other commands to <C-h> and none of them worked.
> The log I got from aerc > aerc.log shows that the mapped commands never
> got triggered so I believe it is an issue with capturing the keybinds.
>
> Coco

Hey Coco -

What terminal are you using, and are you inside a tmux session at all?

-- 
Tim

On Tue Jul 16, 2024 at 9:09 PM CST, Tim Culverhouse wrote:
> What terminal are you using, and are you inside a tmux session at all?

Hi Tim!

I'm using tmux in the foot terminal.
The bug only exists when I am in a tmux session.
The <C-h> binding works as expected in foot.

Sorry I just realized I forgot to cc the mailing list when I replied the
info above yesterday 😬.

Thank you!
Coco

On Tue Jul 16, 2024 at 9:24 AM CDT, Coco Liliace wrote:
> Hi Tim!
>
> I'm using tmux in the foot terminal.
> The bug only exists when I am in a tmux session.
> The <C-h> binding works as expected in foot.

Thanks!

So the issue is that tmux is sending Ctrl+h as 0x08 (which is correct). Vaxis is
translating this to a backspace keypress - because some terminals use 0x08 as
backspace. *Most* use 0x7F as backspace nowadays.

Tcell was using terminfo to decide which of those two keys was actually
backspace - which is why it worked there. Vaxis doesn't use terminfo so it isn't
privvy to this knowledge and assumes that both 0x08 *and* 0x7f are backspace.

I think this might be worthy of changing though. It's very uncommon to find a
terminal which uses 0x08 as backspace - and they almost universally allow
configuring this (tmux included).

-- 
Tim

On Tue Jul 16, 2024 at 10:36 PM CST, Tim Culverhouse wrote:
> So the issue is that tmux is sending Ctrl+h as 0x08 (which is correct). Vaxis is
> translating this to a backspace keypress - because some terminals use 0x08 as
> backspace. *Most* use 0x7F as backspace nowadays.
>
> Tcell was using terminfo to decide which of those two keys was actually
> backspace - which is why it worked there. Vaxis doesn't use terminfo so it isn't
> privvy to this knowledge and assumes that both 0x08 *and* 0x7f are backspace.
>
> I think this might be worthy of changing though. It's very uncommon to find a
> terminal which uses 0x08 as backspace - and they almost universally allow
> configuring this (tmux included).

Hi Tim,

Thanks for the explanation! It sounds like an upstream issue if I am
understanding it correctly, so I will open an issue there :)

Thank you,
Coco

I just found this trying to figure the same thing out. I'm seeing the
same behavior on wezterm and vanilla xterm in Arch/Wayland, no
multiplexing involved.

On Tue Jul 16, 2024 at 11:08 AM EDT, Coco Liliace wrote:
> On Tue Jul 16, 2024 at 10:36 PM CST, Tim Culverhouse wrote:
> > So the issue is that tmux is sending Ctrl+h as 0x08 (which is correct). Vaxis is
> > translating this to a backspace keypress - because some terminals use 0x08 as
> > backspace. *Most* use 0x7F as backspace nowadays.
> >
> > Tcell was using terminfo to decide which of those two keys was actually
> > backspace - which is why it worked there. Vaxis doesn't use terminfo so it isn't
> > privvy to this knowledge and assumes that both 0x08 *and* 0x7f are backspace.
> >
> > I think this might be worthy of changing though. It's very uncommon to find a
> > terminal which uses 0x08 as backspace - and they almost universally allow
> > configuring this (tmux included).
>
> Hi Tim,
>
> Thanks for the explanation! It sounds like an upstream issue if I am
> understanding it correctly, so I will open an issue there :)
>
> Thank you,
> Coco

On Wed Aug 7, 2024 at 8:20 PM CDT, Dian Fay wrote:
> I just found this trying to figure the same thing out. I'm seeing the
> same behavior on wezterm and vanilla xterm in Arch/Wayland, no
> multiplexing involved.

In wezterm, this should work if you enable kitty keyboard.

The issue is that <C-h> is encoded as 0x08, which *can* mean backspace, but also
0x7f can mean backspace. Terminfo *can* give you this information, however many
terminals allow the user to modify this at runtime so it isn't very reliable.
Also our TUI library has the expressed goal of *not* using terminfo.

So - <C-h> in the absence of kitty keyboard does not map to a key in the TUI
library. Depending on the context of your keybind, you should be able to map
"Backspace" to it and it should work.

-- 
Tim

On Thu Aug 8, 2024 at 11:37 AM EDT, Tim Culverhouse wrote:
> On Wed Aug 7, 2024 at 8:20 PM CDT, Dian Fay wrote:
> > I just found this trying to figure the same thing out. I'm seeing the
> > same behavior on wezterm and vanilla xterm in Arch/Wayland, no
> > multiplexing involved.
>
> In wezterm, this should work if you enable kitty keyboard.
>
> The issue is that <C-h> is encoded as 0x08, which *can* mean backspace, but also
> 0x7f can mean backspace. Terminfo *can* give you this information, however many
> terminals allow the user to modify this at runtime so it isn't very reliable.
> Also our TUI library has the expressed goal of *not* using terminfo.
>
> So - <C-h> in the absence of kitty keyboard does not map to a key in the TUI
> library. Depending on the context of your keybind, you should be able to map
> "Backspace" to it and it should work.

Thanks for the hint & explanation, that setting fixes it in wezterm and
I don't usually use xterm :)