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
key-bindings fail if user used keyseqs have non-default assignments #3461
Comments
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). Lines 121 to 123 in e833823
or Lines 132 to 134 in e833823
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) we might be able to solve (at least for bash versions whose I do think, that solving it should definitely be done if possible, even if it means a bunch of extra code. (2) is a bit special, so maybe it would make sense to handle it in it's own issue. |
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 Quoting myself:
if you're curious, you can already look there, how I think we could perhaps do it. |
Oh and to re-iterate: |
man fzf
)Info
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:
form of
bind
, that isAlt-C
for old and current bash versions:fzf/shell/key-bindings.bash
Lines 132 to 134 in 4fdc082
as well as all the key-bindings for the ancient versions of bash:
fzf/shell/key-bindings.bash
Lines 110 to 118 in 4fdc082
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:
and then has a readline like:
(i.e. no
Enter
pressed yet and the cursor being at the end of the line) and now doesAlt-C
one gets e.g. something like:now I select
go
andEnter
and I get a readline like:(i.e. the
d
swallowed and the cursor is now at thea
), which is not just a visual glitch as pressingEnter
causes:The text was updated successfully, but these errors were encountered: