Can't Navigate Containers with Arrow Keys in st

[JBlocklove]

How have you installed cordless

• Arch User Repository
• Snap
• scoop
• brew
• go get

What happened

I can't seem to navigate containers using Alt+arrow from st

How do you reproduce this bug

I am using st as my terminal, which seems to relate to the issue. When I try on urxvt it works fine. I assume this has something to do with the way the keycodes are sent for compatibility purposes.

This issue occurs both with an unmodified install of st as well as with my somewhat customized one.

Error output

No output

System information

Key	Value
OS	Arch Linux
Architechture	5.5.2-arch1-1

[Bios-Marcel]

This isn't fixable. However, the workaround on my side is to make the arrow key navigation reconfigurable I think.

[JBlocklove]

One idea might be to have a reconfigurable modifier key. Rather than only using alt you could allow the user to set it to ctrl or something like that. Still not sure how that would play with st but maybe?

This could also be helped by a vim mode, like in #140. Alt+<hjkl> seems to work just fine, and should on most terminals.

[avahe-kellenberger]

@JBlocklove Can you provide more information about your build of st? I'm able to navigate with Alt+arrows in st just fine

[JBlocklove]

@avahe-kellenberger Sure. I my build was forked from Luke Smith's build and can be found here: https://github.com/JBlocklove/st
That said, I tried a fresh install straight from suckless and had the same issue. I just did again to make sure and there's no change for me.

[avahe-kellenberger]

I'll do some debugging tonight and see if I can figure out why my building is working but the default isn't

[avahe-kellenberger]

@JBlocklove Using the default build of st works just fine. Your version of st has these bindings which interfere with cordless:

#define MODKEY Mod1Mask
...
	{ MODKEY,               XK_Up,          kscrollup,      {.i =  1} },
	{ MODKEY,               XK_Down,        kscrolldown,    {.i =  1} }

Mod1Mask is the alt key, and you have bindings for alt+up and alt+down.

It may be a good idea to allow remapping of arrow key navigation as @Bios-Marcel suggested, but this is an issue with your personal configuration

[JBlocklove]

@avahe-kellenberger Ah, it seems I haven't pushed my most recent build -- it should be up to date now. Those lines were the first things I removed when trying to solve this. Also, the stock build definitely doesn't work for me, unless I'm doing something wrong. These are the exact commands I'm running:

git clone https://git.suckless.org/st
cd st
sudo make install

Then I restart my terminal, and the configs are definitely reset to the stock ones and it's not working.

If I'm messing up somewhere in this that's fine, I just don't know where.

[Bios-Marcel]

maybe your system sends different sequences to the terminal for some reason. There's a demo file in cordless: https://github.com/Bios-Marcel/cordless/blob/master/tools/keyevents/main.go

Can you run that, do the broken shortcuts and send the output?

[JBlocklove]

Each shortcut alt+<arrow> in st gives 5 lines of output:

alt+Up:

256 4 91
256 0 49
256 0 59
256 0 51
256 0 65

alt+Right:

256 4 91
256 0 49
256 0 59
256 0 51
256 0 67

alt+Down:

256 4 91
256 0 49
256 0 59
256 0 51
256 0 66

alt+Left:

256 4 91
256 0 49
256 0 59
256 0 51
256 0 68

I also ran this in Urxvt where the navigation works correctly, and each combination only produced one code:
alt+Up: 257 4 0
alt+Right: 259 4 0
alt+Down: 258 4 0
alt+Left: 260 4 0

Also, is there a way to quit out of this program? I've just been externally killing it for this test...

[Bios-Marcel]

no way to kill it, sry xD

Well, now this is a weird and unexpected result. The 256 stands for KeyRune, meaning it's a key that represents a character such as a or 1, which is very weird. The 4 is ModAlt and the 0 is ModNone. I have no explanation for this.

[Bios-Marcel]

Might be a bug in tcell, as we are not doing anything low-level in cordless.

[Bios-Marcel]

This seems to be related: gdamore/tcell#309

[avahe-kellenberger]

@JBlocklove try make followed by ./st to ensure you're running the correct binary. It worked perfectly fine on my system

[JBlocklove]

@avahe-kellenberger I get make: 'st' is up to date. when I run make ./st

I also get the same output from the keyevents program.

[avahe-kellenberger]

I meant as two separate commands, make and then ./st to run the local binary. You should try completely wiping that directory and clone the project, first. It will open another terminal window (default st) where you could run cordless and try again

[JBlocklove]

Still the same result. I've tried just about every iteration of getting the stock build of st. It doesn't work for me.

[Bios-Marcel]

This issue might be fixed with gdamore/tcell#369

[Bios-Marcel]

Hey @JBlocklove cordless upgraded to tcell v2. If you still care about this issue and it still persists, just reopen / make a new issue.

[JBlocklove]

Sorry, never noticed that the change was made. I just tried with both the AUR and building from source after pulling from master and still no dice. The keyevents tool still seems to give me the same responses, as well. I also tried with a clean build of st again and still no dice. I can't reopen this issue since I'm not the one who closed it, so I'll open a new one with this info as well.