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

[jsoo1]

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

[jsoo1]

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]

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]

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]

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]

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.

[krader1961]

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.

[einnjo]

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