Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improper handling for home, end, delete, pageup and pagedown keys after upgrade to 2.4 #3731

loadaverage opened this issue Jan 13, 2017 · 6 comments
bug Something that's not working as intended regression


Copy link

loadaverage commented Jan 13, 2017

Just after upgrade to version 2.4, keys "insert", "home", "end", "delete", "pageup", "pagedown" switch Fish in vi mode (differs for different emulators).

Before upgrade just Escape was the switch key for the vi mode.

Is there some workaround?

OS: Debian GNU/Linux testing (stretch)
Fish version: 2.4.0
Terminal emulators: terminator 0.97-r1, sakura 3.3.4

How to reproduce:

  • create new user with clean home dir;
    useradd test -d /home/test -s `which fish` && mkdir /home/test && chown test.test /home/test
  • become test user;
    su test
  • enable vi bindings;
  • press some of "insert", "home", "end", "delete", "pageup", "pagedown" keys

In Terminator any of "insert", "home", "end", "delete", "pageup" or "pagedown" keys will turn on vi mode, however in Sakura all except "home" and "end" keys will.


Copy link

krader1961 commented Jan 13, 2017

I don't understand. Enabling vi mode is done by executing fish_vi_key_bindings. No key will "turn on" vi mode unless you have a custom binding that runs that function when the key is pressed. Do you mean that pressing the key is switching from insert mode to default/command mode? If the answer is yes it may be that the escape delay is too low for your environment. You can use the fish_key_reader program to see the delay between the escape character and the rest of the sequence corresponding to the key. For example, here I pressed the [left-arrow] key after running that command:

Press a key

              hex:   1B  char: \c[  (or \e)
(  0.347 ms)  hex:   5B  char: [
(  0.337 ms)  hex:   44  char: D
bind \e\[D 'do something'

You can see that 0.347 milliseconds elapsed between reading the escape character and the next character in the sequence. See the discussion of the fish_escape_delay_ms variable in the documentation

Copy link

L3nn0x commented Jan 14, 2017

I have the same problem.
Upgrading from 2.3 without touching any config file makes the delete/page up/page down keys switch to normal mode and display the previous command.

Changing the fish_espace_delay_ms variable doesn't help. All it does is make the shell pause longer when switching "normally" (using escape).

EDIT : remapping the delete key (bind -M insert \e\[3~ do_something) in insert mode did the trick for me.

Copy link

krader1961 commented Jan 14, 2017

Okay, what's happening is that prior to 2.4.0 fish_vi_key_bindings actually created what we now call "hybrid" key bindings to layer vi bindings on top of emacs bindings. And [prev-page] and [next-page] are only defined in the default (emacs) bindings.

As of 2.5.0 you can get that behavior by using the fish_hybrid_key_bindings. Fish 2.4.0 doesn't have that function but creating it is documented here.

It looks like the [delete] key not being available in vi mode is a regression. The [home] and [end] keys should work in vi default mode, but don't, and should not work in insert mode if we want maximum compatibility with vi/vim. It looks like prior to 2.3.0 they worked in both modes and when we refactored the bindings overlooked moving those to the __fish_shared_key_bindings function.

@krader1961 krader1961 added bug Something that's not working as intended regression and removed needs more info labels Jan 14, 2017
@krader1961 krader1961 added this to the fish 2.5.0 milestone Jan 14, 2017
@krader1961 krader1961 self-assigned this Jan 14, 2017
Copy link

krader1961 commented Jan 14, 2017

We'll want to fix this ASAP and cherry-pick it into the 2.5.0 branch.

krader1961 added a commit that referenced this issue Jan 15, 2017
Copy link

loadaverage commented Jan 16, 2017

@krader1961 Sorry for the delay.
Yes, I meant command mode (and I have vi mode enabled in command mode too).
I'll wait for update.

@L3nn0x thanks for the workaround

Copy link

loadaverage commented Mar 29, 2017

Another workaround:

  bind -M insert -k home beginning-of-line 2>/dev/null   
  bind -M insert -k end end-of-line 2>/dev/null   
  bind -M insert -k dc delete-char 2>/dev/null   

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
bug Something that's not working as intended regression
None yet

No branches or pull requests

3 participants