Enable arrow keys about fzf HOT 21 CLOSED

Actually, arrow keys are already supported. It works as expected on my Macbook. Did you try it?

from fzf.

I got MacBook Air with OS X 10.9.1. When I hit arrow key in interactive shell A/B/D/C is being printed instead of navigation functions.

from fzf.

That's strange. Which terminal emulator do you use?
I've tested those keys on the followings and had no problem.

• Terminal.app on OSX
• iTerm2 on OSX
• urvxt on OSX
• putty on Windows 7

from fzf.

I use iTerm2, this build.

from fzf.

I've tested with the version from the link, but it seems to work just fine. It's really hard to fix the problem when I can't reproduce it 😕

I'm working on experimental mouse-support on another branch, mouse, which by the way employs a different method to accept user input. So if you have time, check out the branch, and see if it helps.

EDIT: mouse branch has been merged to master and deleted

from fzf.

I have experienced the same issue last night but haven't been able to reproduce it since it occurred. At the time I was in a tmux session and the command I ran was gvim --remote fzf``.

Some System info

• urvxt while in a tmux session
• Arch 3.12.9-1 (as of last night)
• on commit 3723829

from fzf.

@Taar Thanks for the report. So it's not easily reproducible. 😕 Could you please update fzf to the latest revision (which adds support for mouse input) and see if the problem is reproducible? As I've mentioned in the earlier comment, the new version uses a different method for taking user input, so I'm curious if it has any effect on this problem.

from fzf.

@junegunn updated. I'll let you know if it happens again :)

from fzf.

Yeah! It's gone!
Latest update (commit #eca0a99fb4) fixed it somehow.

from fzf.

Whoops, I got this bug again on latest commit (db58182), it appears in history search (Ctrl+R), but not in usual fzf call. Shell is zsh, Mac OS X 10.9.2, iTerm2 (Build 1.0.0.20140507-nightly). Instead of navigation functions arrows give me symbols A, B, C and D.

from fzf.

I don't think fzf should behave differently whether it's used in history search or not. Could you try different terminal emulator, like the default Terminal.app?

Actually I reverted the change (which introduced the use of Curses.getch) that initially fixed the problem for you, because I found out later that it had made the rendering really unstable. However, since then I made some effort to make such keys with escape sequences work correctly on most terminal emulators. I personally had no issue so far, possibly because I almost never use arrow keys (I find CTRL-B/F/J/K much easier to reach), but yeah I suppose it's not perfect. Unfortunately I'm not aware of a better way to handle that.

Anyway the change was made 2 months ago, when was the last time you updated fzf?

from fzf.

I installed latest fzf on a new macbook a day ago.
Have the same behaviour in Terminal.app :(

from fzf.

It's really strange, I use two macbooks regularly (air and pro). And I have no problem on iTerm2, Terminal.app and even on urxvt. Let's check a couple of things.

1. Do you use an external keyboard? (I don't, so.. )
2. Does it happen even when you're on tmux?

from fzf.

1. No, built-in keyboard.
2. I don't use tmux :(

from fzf.

I would to file another report related to the arrow keys:

First some info: I'm using the most recent github version of fzf on zsh-5.0.0.

Whenever I execute a zsh widget involving fzf for the first time in a new terminal window, the arrow keys do not work. Instead of going up an down, the letters A and B (respectively) are inserted.

• If I quit fzf (CTRL-C) and re-execute the widget, the arrow keys work as expected. This behaviour is shared among all widgets, i.e. after the first widget has been closed, the arrow keys work in all subsequently opened widgets. If two widgets are opened in parallel (meaning the first is not closed before the second was opened,) the problem persists in both instances of the widget.
• I can enter any commands prior to calling the widget and the widget will still suffer from the arrow key problem.
• I can manually execute the command which is used internally by the widget and the arrow keys will work. Closing this "non-widget" version of the command DOES NOT fix the problem. A subsequently opened widget-version of the command will still not be able to use the arrow keys properly.

I have observed this bug in xfce4-terminal and uxterm.

from fzf.

@roboslone I tested again on my coworker's new macbook, but it worked fine. So it's three macbooks. It would be really helpful if you could try on another macbook and let me know of the result. If the problem is not reproducible there, you can further investigate what's causing the issue, configuration differences, etc.

@elemakil Thanks. Yes, I can reproduce the problem on a Ubuntu desktop. I'm not an expert of zsh, but I'll see what I can do. Could be a bug of zsh. In the meantime, you can always use CTRL-J(N)/K(P)/B/F instead :)

from fzf.

Wow, @elemakil is totally right! Didn't notice that.

from fzf.

@elemakil I have just pushed a commit that seemingly fixes the problem. Strangely, the escape sequences of arrow keys in that case are prefixed by 27-79 instead of 27-91. Please update fzf and try again.

@roboslone I don't know if it applies to your case, but could you check if it helps?

from fzf.

@junegunn Splendid! It's now working as expected. Thanks for the swift response and fix!

from fzf.

@junegunn, works fine, thank you!

from fzf.

@elemakil @roboslone Great. I still don't understand why we're getting different escape sequences. But I found an article and it shows that the problem is not new at least for OSX.

http://www.uponmyshoulder.com/blog/2010/os-x-10-6-3-broke-ncurses/

from fzf.