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

Unusual behaviour with fn+backspace in insert mode in fish vi mode #3739

Closed
2 tasks done
tanc opened this issue Jan 16, 2017 · 10 comments
Closed
2 tasks done

Unusual behaviour with fn+backspace in insert mode in fish vi mode #3739

tanc opened this issue Jan 16, 2017 · 10 comments
Milestone

Comments

@tanc
Copy link

tanc commented Jan 16, 2017

  • Have you checked if problem occurs with fish 2.4.0?
  • Tried fish without third-party customizations (check sh -c 'env HOME=$(mktemp -d) fish')?

fish version installed (fish --version): 2.4.0

OS/terminal used: iTerm2 (2.7.1) - OS X

With the vi mode enabled in fish and whilst in insert mode the fn + backspace very weirdly, I can't work out what exactly its doing. It appears to do one of the following:

  1. Remove a character, replace it with uppercase version and move to end of word.
    2 Paste in a previous command, move to end of word.
    3 Paste in a part of a previous command, move to end of word.

Reproduction steps

  1. Open a new fish shell and issue sh -c 'env HOME=$(mktemp -d) fish' for a clean version.
  2. Enable vi mode with fish_vi_key_bindings
  3. Write some text in insert mode
  4. Move cursor backwards and use fn+backspace
  5. Repeat on different characters to see the effect.

I can possibly post a video if these steps don't reproduce the problem.

@krader1961
Copy link
Contributor

Please run fish_key_reader then press the key that is giving you problems. The symptoms you're describing imply we simply don't have a binding for it since if it sends an escape sequence the initial escape will switch from insert to default/command mode. Then the remaining characters in the sequence will do whatever they're bound to in vi default mode.

@faho
Copy link
Member

faho commented Jan 16, 2017

The "fn" key isn't actually a defined and standardized thing. On all computers I've owned, it's been the special "make these other keys send the special sequence" key. If you held it down, other things would send stuff like volume up/down or brightness or switching monitors (fun fact: my current one sends win+p for that one).

As I've never owned Apple hardware, I have no idea what it's supposed to send here.

Please execute fish_key_reader and press whatever combination you're testing. It should tell you what sequence fish receives, and then we can argue about what it should do.

@tanc
Copy link
Author

tanc commented Jan 16, 2017

Thanks both for your replies!

The result of fish_key_reader is:

              hex:   1B  char: \c[  (or \e)
(  0.466 ms)  hex:   5B  char: [
(  0.418 ms)  hex:   33  char: 3
(  0.396 ms)  hex:   7E  char: ~
bind -k dc 'do something'
bind \e\[3~ 'do something'

@faho
Copy link
Member

faho commented Jan 16, 2017

Well, that's just the sequence for the delete key.

The issue here is probably that delay - 0.466ms between sending \e (the escape character) and [. We use a timeout to figure out whether you've pressed escape or another key, and it's likely that timeout was reached, so it's executing the binding for escape, and then bindings for the rest.

Try set fish_escape_delay_ms 600. That will increase the timeout to 600ms - which also means fish will wait 600ms after you've pressed escape to enter normal mode.

Also, since it sends the sequence for delete, there's no way to bind fn+backspace to something different than delete.

@tanc
Copy link
Author

tanc commented Jan 16, 2017

after set fish_escape_delay_ms 600 the behaviour is the same in that the fn+backspace isn't binding to delete as expected. There is now a delay after hitting the escape key though.

@faho
Copy link
Member

faho commented Jan 16, 2017

the behaviour is the same in that the fn+backspace isn't binding to delete as expected.

Sorry, I'm having trouble parsing that sentence. Does the changed timeout change anything about how fn+backspace behaves?

@tanc
Copy link
Author

tanc commented Jan 16, 2017

The changed timeout does not change anything about the behaviour of fn+backspace.

Note that this is only a problem in 'insert' mode. While in 'normal' mode fn+backspace works as the delete key as expected.

@faho
Copy link
Member

faho commented Jan 16, 2017

Can you try increasing it some more? 1000?

Note that this is only a problem in 'insert' mode. While in 'normal' mode fn+backspace works as the delete key as expected.

Ah, okay. So escape isn't bound in normal mode, so there's no ambiguity there and hence no possibility of it timeing out and executing the escape binding. In insert mode delete is only bound since d37e7bc.

So you'll need that commit and a higher fish_escape_delay_ms.

I can't see what else we can do here.

@tanc
Copy link
Author

tanc commented Jan 16, 2017

ok great, I'll give that a try and report back. Thanks for your help!

@krader1961
Copy link
Contributor

My apple keyboards don't have a [backspace] key. However, pressing [fn][delete] sends the sequence you listed. Commit d37e7bc to fix #3731 that I merged yesterday before you opened this issue adds a binding for vi insert mode for that sequence. It will be in fish 2.5.0 or you can install from git head or you can just add bind -M insert -k dc delete-char to your fish_user_key_bindings function.

Also, do not set fish_escape_delay_ms. Faho didn't notice that the fkr output is already in milliseconds and fractions thereof. The interval between the escape and the next char was less than 1/2 of a millisecond. The default of 100 ms is already two orders of magnitude longer than you need.

@zanchey zanchey added this to the fish 2.5.0 milestone Jan 17, 2017
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants