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

Closed
loadaverage opened this Issue Jan 13, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@loadaverage

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;
    fish_vi_key_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.

Thanks.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jan 13, 2017

Contributor

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

Contributor

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

@L3nn0x

This comment has been minimized.

Show comment
Hide comment
@L3nn0x

L3nn0x 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.

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.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jan 14, 2017

Contributor

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.

Contributor

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 this to the fish 2.5.0 milestone Jan 14, 2017

@krader1961 krader1961 self-assigned this Jan 14, 2017

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jan 14, 2017

Contributor

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

Contributor

krader1961 commented Jan 14, 2017

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

@loadaverage

This comment has been minimized.

Show comment
Hide comment
@loadaverage

loadaverage 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

@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

@loadaverage

This comment has been minimized.

Show comment
Hide comment
@loadaverage

loadaverage 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   

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   
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment