key-bindings fail if user used keyseqs have non-default assignments

[calestyo]

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
  • Mac OS X
  • Windows
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Problem / Steps to reproduce

Hey.

This is the issue that I've originally tried to solve with #3448, but failed miserably to do so at first. 😇😅

See also the discussion at #3448 (review) for some ideas.

To round up the problem:

Any key-bindings that hat use the:

bind [-m keymap] keyseq:readline-command

form of bind, that is Alt-C for old and current bash versions:

fzf/shell/key-bindings.bash

Lines 132 to 134 in 4fdc082

	bind -m emacs-standard '"\ec": " \C-b\C-k \C-u`__fzf_cd__`\e\C-e\er\C-m\C-y\C-h\e \C-y\ey\C-x\C-x\C-d"'
	bind -m vi-command '"\ec": "\C-z\ec\C-z"'
	bind -m vi-insert '"\ec": "\C-z\ec\C-z"'

as well as all the key-bindings for the ancient versions of bash:

fzf/shell/key-bindings.bash

Lines 110 to 118 in 4fdc082

	# CTRL-T - Paste the selected file path into the command line
	bind -m emacs-standard '"\C-t": " \C-b\C-k \C-u`__fzf_select__`\e\C-e\er\C-a\C-y\C-h\C-e\e \C-y\ey\C-x\C-x\C-f"'
	bind -m vi-command '"\C-t": "\C-z\C-t\C-z"'
	bind -m vi-insert '"\C-t": "\C-z\C-t\C-z"'
	# CTRL-R - Paste the selected command from history into the command line
	bind -m emacs-standard '"\C-r": "\C-e \C-u\C-y\ey\C-u`__fzf_history__`\e\C-e\er"'
	bind -m vi-command '"\C-r": "\C-z\C-r\C-z"'
	bind -m vi-insert '"\C-r": "\C-z\C-r\C-z"'

are prone to fail, namely when any of the keyseqs used in the readline-command are already assigned in a non-default way.

Example as of current master:
If one defines:

~$ bind -m emacs-standard -x '"\C-b\C-k": foo'
~$ foo() { :; }

and then has a readline like:

~$ date

(i.e. no Enter pressed yet and the cursor being at the end of the line) and now does Alt-C one gets e.g. something like:

~$ `__fzf_cd__`
>                                                                                                                                                                                             
  97/97 ──────────────────────────────────────────────────────────
> go
  go/pkg
  go/pkg/mod

now I select go and Enter and I get a readline like:

~/go$ ate

(i.e. the d swallowed and the cursor is now at the a), which is not just a visual glitch as pressing Enter causes:

~/go$ ate  
-bash: ate: command not found

[calestyo]

There's a similar issue in that we override bindings for "internal purposes", which the user may however have set (or may (re-)set after our code has been sourced).
I don't mean bindings like:

fzf/shell/key-bindings.bash

Lines 121 to 123 in e833823

	bind -m emacs-standard -x '"\C-t": fzf-file-widget'
	bind -m vi-command -x '"\C-t": fzf-file-widget'
	bind -m vi-insert -x '"\C-t": fzf-file-widget'

or

fzf/shell/key-bindings.bash

Lines 132 to 134 in e833823

	bind -m emacs-standard '"\ec": " \C-b\C-k \C-u`__fzf_cd__`\e\C-e\er\C-m\C-y\C-h\e \C-y\ey\C-x\C-x\C-d"'
	bind -m vi-command '"\ec": "\C-z\ec\C-z"'
	bind -m vi-insert '"\ec": "\C-z\ec\C-z"'

For these it's clear that they must be set and it's the users duty to keep them "free" (though we should make them configurable).

But I do mean bindings like:

1. fzf/shell/key-bindings.bash

   Lines 103 to 107 in e833823

   	bind -m emacs-standard '"\er": redraw-current-line'
   	bind -m vi-command '"\C-z": emacs-editing-mode'
   	bind -m vi-insert '"\C-z": emacs-editing-mode'
   	bind -m emacs-standard '"\C-z": vi-editing-mode'

   
   and actually also:

2. fzf/shell/completion.bash

   Lines 34 to 35 in e833823

   	# To redraw line after fzf closes (printf '\e[5n')
   	bind '"\e[0n": redraw-current-line' 2> /dev/null

(1) we might be able to solve (at least for bash versions whose bind support -x) as roughly described in the next reply to this issue.

I do think, that solving it should definitely be done if possible, even if it means a bunch of extra code.

I, for example, have already bound C-h to something custom and I guess for "power shell" users, which are likely to use fzf one can also assume that they have already set up their own bindings.

(2) is a bit special, so maybe it would make sense to handle it in it's own issue.

Either it could be solved in a similar fashion to (1), or we could at least do something like freshly set up the bind everytime it's needed (i.e. before every printf '\e[5n').

The latter might be enough, but would require that any other program that uses the \e[5n/\e[0n trick does so as well, so that many of them could co-exist.

[calestyo]

As mentioned above, I might have found a solution for the problems described above, though I would tentatively say that it only works with versions of bash that already support bind -x (I guess at least in the Linux world, this should be everyone? ^^ ... and maybe Mac will sooner or later update, too).

Quoting myself:
It's not yet perfect and I'm not enough of a bash/readline expert to determine whether it really works properly and in all cases, so I wrote mails to help-bash, asking for their advice:

• https://lists.gnu.org/archive/html/help-bash/2023-10/msg00000.html
• https://lists.gnu.org/archive/html/help-bash/2023-10/msg00001.html

if you're curious, you can already look there, how I think we could perhaps do it.

[calestyo]

Oh and to re-iterate:

I think in order to solve the issue for the \e[5n/\e[0n, it would be enough to just always set the binding again... save&restore (as needed for the other cases), would probably be overkill for that specific case.