yorukot
Arrow keys behave as if stuck when held down a second or two
Describe the bug If I press and hold an arrow key - any arrow key, this may even apply to other keys but I've not tested - it behaves as if the key is still held down even after I release. This behavior happens on both LinuxMint and Debian devices I use, but does not replicate in other apps, including bash itself, GTK gui apps, or even stuff like midnight commander, so I'm quite certain it isn't my keyboard.
To Reproduce Steps to reproduce the behavior:
- Run
spffrom terminal - Press and hold any arrow key (up and down in particular make this obvious) for 1-2 seconds.
- Release the key and watch it continue to scroll as if your key is stuck.
- Pressing the opposing key or another key to try and break the input loop doesn't consistently work but it tends to "eventually" stop doing this.
Expected behavior As soon as the key is released, there should be no further inputs registered and the selection cursor should stop where it is.
Screenshots I was using a physical TTY for both cases, so have no good way to get these
System information (please complete the following information):
- OS: Linux
- Version: Debian 12 and LinuxMint, likely others
- superfile Version - latest release I downloaded yesterday using the install script
Also, should note, the same occurs if I press the key repeatedly, like around 5+ times. This seems to me like it's a problem with how your input buffer is implemented
One possible reason I can think of is scrolling through files that are rendering-heavy. For example images. But that issue is fixed and is pending release
- https://github.com/yorukot/superfile/issues/899
It still is likely due to synchronous rendering, and previous input still being processed even after you have stopped pressing the keys.
(1) Does it happens everywhere ? Try it on a directory with just 2-3 files.
(2) Does it happens on latest main ? Try to clone the repo and run it via go run main.go
It's mainly the root of my /home directory where I tested. I'll try it somewhere smaller, and see about cloning as described when I get the chance.
Still, this should really be handling the input better IMO.
So I did a test on the mint install and launched it in byobu (layer atop tmux) and the issue didn't occur.
I also tested from a terminal emulator in Cinnamon on LinuxMint, and it also didn't occur there, so this particular problem is specific to when it runs directly from a TTY login shell.
Unfortunately that's the primarily use case I'm trying it for. I know, I'm weird, I run my GUI on demand, like having my RAM and GPU available for processing.