Receiving Keyboard signals when switching focus in window managers #2864
Comments
|
Ranger has no control over what keystrokes it gets sent. We need to figure out why it's getting the keystrokes and whether we can detect conditions where it shouldn't process keystrokes it receives. |
|
Someone posted about the same issue on reddit. |
|
I have the same problem, I tried with a very old version of ranger, and it does the same. |
|
This seems to be related to this : |
|
Some temporary fix :
|
|
@dionisos2, thank you for the sleuthing! This sounds like a bug in Ncurses then. Please (anyone) ping when the upstream bug is fixed, I'll hold off on closing this issue until then so anyone following this for Ranger specifically gets a ping then. |
Terminals can be asked to report focus events with
print("\x1b[?1004h")
For some reason, our use of curses sends a sequence like that (not
exactly that one, but it contains "1004", you can observe it by
running ranger inside "script").
Then the terminal will send ^[[I and ^[[O for "focus in" and "focus
out" events respectively. This is quite annoying. The proper way
to deal with these is to map them ourselves in all modes (to a nop,
or optionally add some UI feedback).
I do not know how to do that, so turn it off altogether with the
corresponding "l" sequence.
Fixes ranger#2864
|
We need have @krobelus' commit merged. A temporary workaround is to run Ranger in tmux, and adding |
Whenever I open
rangerinside my terminal and when I switch focus to/from ranger it receives signals. I have tried different window managers and with different terminals but it is still the case.The problem doesn't occur when I open ranger as separate process with
kitty -e rangerbut only when I dorangerinside terminal.Runtime Environment
Current Behavior
Receives signals when switching focus.
Expected Behavior
Should not receive signals.
Context
Possible Solutions
Steps to reproduce
The text was updated successfully, but these errors were encountered: