A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Peter Slížik]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Hello,

I created a few useful helper functions and bound them to specified keys.
For example, pressing " inserts a pair of quotes and puts the cursor inside
them, like this: "|".
Another example, pressing a space fixes some of the typos I'm inclined to
do repeatedly, e.g. pyhton<Space> is expanded to python<Space>.

The implementation is quite straightforward, the widget examines LBUFFER
and RBUFFER and modifies LBUFFER accordingly.

_expand_abbreviations ()
{
    if [[ LBUFFER =~ 'this' && RBUFFER == 'that' ]]; then
        LBUFER+='something '    # mind the trailing space
    fi
}

zle -N expand-abbreviations _expand_abbreviations
bindkey ' ' expand-abbreviations

The problem with this solution is that it breaks the way that Ctrl+R
history search works.
Before, typing a space inside Ctrl+R just underlined the space in the
offered string:

% abcd efgh
zsh: command not found: abcd
% <Ctrl+R>*abcd *efgh    # the space is underlined here
bck-i-search: abcd<Space>

After using the " bindkey ' ' expand-abbreviations" command, the space
finishes the Ctrl+R editor and inserts itself in front of the offered text:
% _abcd efgh    # a space prepended before abcd
and I'm not able to continue with the bck-i-search widget any more.

The behavior is identical for other bound keys, e.g. the double quote mark
in the first example with quote duplication.

I'm pretty sure there's something I'm missing in the bindkey command, but
frankly, the documentation is quite complex and I'm not sure what to look
for.

Any suggestions are appreciated.

Best regards,
Peter Slížik

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Mikael Magnusson]

On 7/26/21, Peter Slížik <peter.slizik@gmail.com> wrote:
> Hello,
>
> I created a few useful helper functions and bound them to specified keys.
> For example, pressing " inserts a pair of quotes and puts the cursor inside
> them, like this: "|".
> Another example, pressing a space fixes some of the typos I'm inclined to
> do repeatedly, e.g. pyhton<Space> is expanded to python<Space>.
>
> The implementation is quite straightforward, the widget examines LBUFFER
> and RBUFFER and modifies LBUFFER accordingly.
>
> _expand_abbreviations ()
> {
>     if [[ LBUFFER =~ 'this' && RBUFFER == 'that' ]]; then
>         LBUFER+='something '    # mind the trailing space
>     fi
> }
>
> zle -N expand-abbreviations _expand_abbreviations
> bindkey ' ' expand-abbreviations
>
> The problem with this solution is that it breaks the way that Ctrl+R
> history search works.
> Before, typing a space inside Ctrl+R just underlined the space in the
> offered string:
>
> % abcd efgh
> zsh: command not found: abcd
> % <Ctrl+R>*abcd *efgh    # the space is underlined here
> bck-i-search: abcd<Space>
>
> After using the " bindkey ' ' expand-abbreviations" command, the space
> finishes the Ctrl+R editor and inserts itself in front of the offered text:
> % _abcd efgh    # a space prepended before abcd
> and I'm not able to continue with the bck-i-search widget any more.
>
> The behavior is identical for other bound keys, e.g. the double quote mark
> in the first example with quote duplication.
>
> I'm pretty sure there's something I'm missing in the bindkey command, but
> frankly, the documentation is quite complex and I'm not sure what to look
> for.
>
> Any suggestions are appreciated.

You can use bindkey -M isearch ' ' self-insert to restore the previous behavior.

-- 
Mikael Magnusson

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Bart Schaefer]

On Mon, Jul 26, 2021 at 8:58 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> On 7/26/21, Peter Slížik <peter.slizik@gmail.com> wrote:
> >
> > zle -N expand-abbreviations _expand_abbreviations
> > bindkey ' ' expand-abbreviations
> >
> > The problem with this solution is that it breaks the way that Ctrl+R
> > history search works.
>
> You can use bindkey -M isearch ' ' self-insert to restore the previous behavior.

I  believe you could also do

zle -N magic-space _expand_abbreviations
bindkey ' ' magic-space

because the isearch keymap already understands what (not) to do with
magic-space.

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Peter Slížik]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

Dear Mikael & Bart,

yes, both solutions work.

Taking into account that there are more keymaps, I think that the best
solution would be to remap the keys *only* for the emacs keymap, leaving
the other keymaps untouched.

bindkey -M emacs ' ' expand_abbreviations

But alas, this changes the behavior of isearch, too. The documentation is
really sometimes too wordy and, in cases like this, too terse.

Peter

пон, 26. јул 2021. у 23:10 Bart Schaefer <schaefer@brasslantern.com> је
написао/ла:

> On Mon, Jul 26, 2021 at 8:58 AM Mikael Magnusson <mikachu@gmail.com>
> wrote:
> >
> > On 7/26/21, Peter Slížik <peter.slizik@gmail.com> wrote:
> > >
> > > zle -N expand-abbreviations _expand_abbreviations
> > > bindkey ' ' expand-abbreviations
> > >
> > > The problem with this solution is that it breaks the way that Ctrl+R
> > > history search works.
> >
> > You can use bindkey -M isearch ' ' self-insert to restore the previous
> behavior.
>
> I  believe you could also do
>
> zle -N magic-space _expand_abbreviations
> bindkey ' ' magic-space
>
> because the isearch keymap already understands what (not) to do with
> magic-space.
>

[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Bart Schaefer]

On Tue, Jul 27, 2021 at 3:31 AM Peter Slížik <peter.slizik@gmail.com> wrote:
>
> bindkey -M emacs ' ' expand_abbreviations
>
> But alas, this changes the behavior of isearch, too. The documentation is really sometimes too wordy and, in cases like this, too terse.

I think that's because emacs == main and isearch is initialized from
main ... so if you did that bindkey but only after isearch was
initialized, it might work.  I don't know how you assure that order of
events, though.

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Peter Slížik]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Thank you very much for all the answers. If I may have one more question -
hopefully the last one on this topic. ;-)

As I mentioned before, I used a similar function to take care of " and '
characters.
- Pressing a " inserts two of them and places the cursor inside the pair.
Pressing an ' works in a similar fashion.
- Pressing a backspace inside the pair ("|" or '|', where | is the cursor)
deletes both quotes - the left and the right at the same time.

Now, binding the backspace breaks it for isearch.

zle -N insert-single-quotes _insert_single_quotes
zle -N insert-double-quotes _insert_double_quotes
zle -N remove-quotes _remove_quotes
bindkey "'" insert-single-quotes    # " ' "
bindkey '"' insert-double-quotes    # ' " '
bindkey "^?" remove-quotes    # backspace remove the whole pair
bindkey -M isearch '^?' self-insert    # This does NOT restore the original
functionality.

Instead of restoring the original functionality (deleting the last char),
^? is just inserted into the searched text.

Best regards,
Peter


уто, 27. јул 2021. у 16:51 Bart Schaefer <schaefer@brasslantern.com> је
написао/ла:

> On Tue, Jul 27, 2021 at 3:31 AM Peter Slížik <peter.slizik@gmail.com>
> wrote:
> >
> > bindkey -M emacs ' ' expand_abbreviations
> >
> > But alas, this changes the behavior of isearch, too. The documentation
> is really sometimes too wordy and, in cases like this, too terse.
>
> I think that's because emacs == main and isearch is initialized from
> main ... so if you did that bindkey but only after isearch was
> initialized, it might work.  I don't know how you assure that order of
> events, though.
>

[-- Attachment #2: Type: text/html, Size: 2428 bytes --]

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Bart Schaefer]

On Tue, Jul 27, 2021 at 8:09 AM Peter Slížik <peter.slizik@gmail.com> wrote:
>
> bindkey -M isearch '^?' self-insert    # This does NOT restore the original functionality.

That's because the binding for ^? is supposed to be backward-delete-char

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Peter Slížik]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

OK.

Thank you again for all the answers; I highly appreciate them.

Peter

уто, 27. јул 2021. у 17:42 Bart Schaefer <schaefer@brasslantern.com> је
написао/ла:

> On Tue, Jul 27, 2021 at 8:09 AM Peter Slížik <peter.slizik@gmail.com>
> wrote:
> >
> > bindkey -M isearch '^?' self-insert    # This does NOT restore the
> original functionality.
>
> That's because the binding for ^? is supposed to be backward-delete-char
>

[-- Attachment #2: Type: text/html, Size: 879 bytes --]

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Mikael Magnusson]

On 7/27/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, Jul 27, 2021 at 3:31 AM Peter Slížik <peter.slizik@gmail.com>
> wrote:
>>
>> bindkey -M emacs ' ' expand_abbreviations
>>
>> But alas, this changes the behavior of isearch, too. The documentation is
>> really sometimes too wordy and, in cases like this, too terse.
>
> I think that's because emacs == main and isearch is initialized from
> main ... so if you did that bindkey but only after isearch was
> initialized, it might work.  I don't know how you assure that order of
> events, though.

I think isearch is used as a "local keymap", ie it falls back to main
at runtime if a key is not found in the isearch keymap. Unless you add
bindings to it, it is completely empty.

-- 
Mikael Magnusson

Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works

[Bart Schaefer]

On Tue, Jul 27, 2021 at 3:35 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> I think isearch is used as a "local keymap", ie it falls back to main
> at runtime if a key is not found in the isearch keymap. Unless you add
> bindings to it, it is completely empty.

That makes more sense.