zsh-users
 help / color / mirror / code / Atom feed
* A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
@ 2021-07-26 14:13 Peter Slížik
  2021-07-26 15:58 ` Mikael Magnusson
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Slížik @ 2021-07-26 14:13 UTC (permalink / raw)
  To: zsh

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-26 14:13 A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works Peter Slížik
@ 2021-07-26 15:58 ` Mikael Magnusson
  2021-07-26 21:10   ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Mikael Magnusson @ 2021-07-26 15:58 UTC (permalink / raw)
  To: Peter Slížik; +Cc: zsh

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-26 15:58 ` Mikael Magnusson
@ 2021-07-26 21:10   ` Bart Schaefer
  2021-07-27 10:31     ` Peter Slížik
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2021-07-26 21:10 UTC (permalink / raw)
  To: zsh; +Cc: Peter Slížik

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-26 21:10   ` Bart Schaefer
@ 2021-07-27 10:31     ` Peter Slížik
  2021-07-27 14:51       ` Bart Schaefer
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Slížik @ 2021-07-27 10:31 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 10:31     ` Peter Slížik
@ 2021-07-27 14:51       ` Bart Schaefer
  2021-07-27 15:09         ` Peter Slížik
  2021-07-27 22:35         ` Mikael Magnusson
  0 siblings, 2 replies; 10+ messages in thread
From: Bart Schaefer @ 2021-07-27 14:51 UTC (permalink / raw)
  To: Peter Slížik; +Cc: zsh

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 14:51       ` Bart Schaefer
@ 2021-07-27 15:09         ` Peter Slížik
  2021-07-27 15:42           ` Bart Schaefer
  2021-07-27 22:35         ` Mikael Magnusson
  1 sibling, 1 reply; 10+ messages in thread
From: Peter Slížik @ 2021-07-27 15:09 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 15:09         ` Peter Slížik
@ 2021-07-27 15:42           ` Bart Schaefer
  2021-07-27 15:44             ` Peter Slížik
  0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2021-07-27 15:42 UTC (permalink / raw)
  To: Peter Slížik; +Cc: zsh

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 15:42           ` Bart Schaefer
@ 2021-07-27 15:44             ` Peter Slížik
  0 siblings, 0 replies; 10+ messages in thread
From: Peter Slížik @ 2021-07-27 15:44 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 14:51       ` Bart Schaefer
  2021-07-27 15:09         ` Peter Slížik
@ 2021-07-27 22:35         ` Mikael Magnusson
  2021-07-27 22:38           ` Bart Schaefer
  1 sibling, 1 reply; 10+ messages in thread
From: Mikael Magnusson @ 2021-07-27 22:35 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Peter Slížik, zsh

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works
  2021-07-27 22:35         ` Mikael Magnusson
@ 2021-07-27 22:38           ` Bart Schaefer
  0 siblings, 0 replies; 10+ messages in thread
From: Bart Schaefer @ 2021-07-27 22:38 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Peter Slížik, zsh

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-07-27 22:39 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-26 14:13 A wrong bindkey command breaks the way bck-i-search (Ctrl+R) works Peter Slížik
2021-07-26 15:58 ` Mikael Magnusson
2021-07-26 21:10   ` Bart Schaefer
2021-07-27 10:31     ` Peter Slížik
2021-07-27 14:51       ` Bart Schaefer
2021-07-27 15:09         ` Peter Slížik
2021-07-27 15:42           ` Bart Schaefer
2021-07-27 15:44             ` Peter Slížik
2021-07-27 22:35         ` Mikael Magnusson
2021-07-27 22:38           ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).