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

Rebinding key error messages in emacs ansi, term, or multi-term terminals #4188

Closed
jsoo1 opened this Issue Jul 5, 2017 · 12 comments

Comments

Projects
None yet
6 participants
@jsoo1
Copy link

jsoo1 commented Jul 5, 2017

When opening shell, ansi-term, or multi-term, some key rebinding error messages show up.
Using fisherman.

Seems related to #1155

version 2.6.0
uname -a: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64

Literal output:

bind: Key with name 'btab' does not have any mapping
bind: Key with name 'f1' does not have any mapping
bind: Key with name 'btab' does not have any mapping
bind: Key with name 'f1' does not have any mapping
bind: Key with name 'btab' does not have any mapping
bind: Key with name 'f1' does not have any mapping
john /u/l/C/f/2/s/f/functions (aacom-1) λ echo $TERM
eterm-color
john /u/l/C/f/2/s/f/functions (aacom-1) λ uname -a
Darwin Johns-MacBook-Pro.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
john /u/l/C/f/2/s/f/functions (aacom-1) λ fish --version
fish, version 2.6.0
john /u/l/C/f/2/s/f/functions (aacom-1) λ sh -c 'env HOME=$(mktemp -d) fish'
Welcome to fish, the friendly interactive shell
john@Johns-MacBook-Pro /u/l/C/f/2/s/f/functions> 
@faho

This comment has been minimized.

Copy link
Member

faho commented Jul 5, 2017

This does not happen to me. I'm guessing this is because of macOS' broken "eterm-color" terminfo entries.

Try something like

tic -o ~/.terminfo $TERMINFO/e/eterm-color.ti
# where $TERMINFO is something like "/usr/local/Cellar/emacs-mac/emacs-24.5-z-mac-5.15/share/emacs/24.5/etc/"

Also note that even if you get it working, all emacs terminals are rather limited and won't really give a great experience with fish. I suggest using a more full-featured terminal like iTerm.

@faho faho added the question label Jul 5, 2017

@jsoo1

This comment has been minimized.

Copy link

jsoo1 commented Jul 5, 2017

i have done tic -o ~/.terminfo $TERMINFO/e/eterm-color.ti. I agree that the emacs terminal experience is not the greatest. I think also that there is something more happening from a third party app like fisherman, too.

@faho

This comment has been minimized.

Copy link
Member

faho commented Jul 5, 2017

i have done tic -o ~/.terminfo $TERMINFO/e/eterm-color.ti

What did you use as $TERMINFO? That variable might very well not be set.

The idea is that you use the path to your "eterm-color.ti" file from your (hopefully somewhat modern) emacs installation.

How did you install emacs?

I think also that there is something more happening from a third party app like fisherman, too.

Yes, something weird is happening. We're silencing errors for all binding functions (in __fish_reload_key_bindings), so this should never be printed. It's possible fisherman is setting bindings elsewhere (which is not guaranteed to work - the binding system needs a bit of a reworking).

Anyway, we should probably find a different way to signal that a key cannot be bound. These error messages should be silenced in the core builtin_bind code, not in a function that I'd love to remove entirely.

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Jul 5, 2017

Anyway, we should probably find a different way to signal that a key cannot be bound. These error messages should be silenced in the core builtin_bind code, not in a function that I'd love to remove entirely.

You read my mind. Redirecting stderr to /dev/null like that can hide errors we want to see. I was thinking we should add a -q flag (or maybe -s / --silent) to bind to indicate it shouldn't complain if a key name isn't in the terminfo database.

@jsoo1

This comment has been minimized.

Copy link

jsoo1 commented Jul 5, 2017

Yeah I am on emacs 25. $TERMINFO looks correct (it's the directory of eterm-color.ti at least). Emacs is installed through brew install emacs-plus but the issue appears in the regular emacs as well. (Also, thanks for maintaining such a fun and awesome project, y'all!)

@faho

This comment has been minimized.

Copy link
Member

faho commented Jul 12, 2017

I've thought about this some more, and I'm leaning towards removing these warnings entirely.

In theory, it sounds nice that we warn people that the bind they're using won't work in that terminal, but

  • I'd expect people to use the value fish_key_reader hands them for their particular terminal, which is guaranteed to work.

  • I'd expect that people actually test their bindings on their terminal.

  • Most people never see these warnings even if they are thrown, since we silence them.

  • Plenty of these bindings will go unused in practice - I know I never use our f1 binding - so throwing the error is pointless.

Note that I think this is a manifestation of #1035 - we lose the stderr redirection somewhere along the way.

@faho faho added enhancement and removed question labels Jul 12, 2017

@faho faho added this to the fish 2.7.0 milestone Jul 12, 2017

@krader1961

This comment has been minimized.

Copy link
Contributor

krader1961 commented Jul 21, 2017

I'm changing this from the 2.7.0 milestone to the fish-future milestone. The 2.7.0 milestone is now a bug fix only milestone -- no new features beyond those already included. This change in behavior can be included in the fish 3.0.0 release.

@krader1961 krader1961 modified the milestones: fish-future, fish 2.7.0 Jul 21, 2017

@juanjoLenero

This comment has been minimized.

Copy link

juanjoLenero commented Jul 26, 2017

I'm also experiencing this issue. Is there a way to suppress the output in the meantime?

mqudsi added a commit to mqudsi/fish-shell that referenced this issue Oct 3, 2017

Silence bind errors in default key bindings
This silences binding errors due to keys not found in the current
termcap config in the default fish bindings.

Closes fish-shell#4188, fish-shell#4431, and obviates the original fix for fish-shell#1155

mqudsi added a commit to mqudsi/fish-shell that referenced this issue Oct 3, 2017

Silence bind errors in default key bindings
This silences binding errors due to keys not found in the current
termcap config in the default fish bindings.

Closes fish-shell#4188, fish-shell#4431, and obviates the original fix for fish-shell#1155

It was necessary to re-implement builtin_bind as a class in order to
avoid passing around the options array from function to function and
as adding an opts parameter to `get_terminfo_sequence` would require
otps to be passed to all other builtin_bind_ functions so they could, in
turn, pass it to `get_terminfo_sequence`.

@mqudsi mqudsi closed this in 46d1334 Oct 3, 2017

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Oct 3, 2017

fish 3 will not emit warnings for the default bindings (including vi mode) when keys are not found in the for the current $TERMINAL in termcap. User bindings can specify -s or --silent to bind to obtain the same behavior.

@joehillen

This comment has been minimized.

Copy link

joehillen commented Oct 3, 2017

I just accidentally solved this myself!

There was a ~/.config/fish/fishd.* file that was causing another issue. After deleting it and running killall fish the warnings no longer appear when launching fish in ansi-term.

@mqudsi

This comment has been minimized.

Copy link
Contributor

mqudsi commented Oct 4, 2017

That’s your configuration file, so you simply worked around the problem by not binding the keys in question any more.

@joehillen

This comment has been minimized.

Copy link

joehillen commented Oct 4, 2017

It had old stuff in it that wasn't in my config.fish file anymore and no amount of refreshing was fixing it. I discovered the problem when I was grepping around because fish was complaining that a dir in my path didn't exist, but as near as I could tell that dir wasn't set it my path anywere. But it was still in the fishd.* file. Doing a hard refresh by deleting the file "solved" the problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment