Re: zle oddity or some option running wild?

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Jun 27, 2024 at 9:08 AM Thomas Lauer <thomas.lauer@virgin.net> wrote:
>
> From: Peter Stephenson <p.w.stephenson@ntlworld.com>
> Date: Thu, 27 Jun 2024 16:41:50 +0100 (BST)
>
> > This is likely to be something to do with the "zle -f" stuff documented
> > in the zshzle manual page
>
> Whatever the cause, select-word-style seems to change something globally
> in a way that isn't helpful (to my use case).

I think it's this:

backward-kill-word-match-    if [[ -n $done || $LASTWIDGET = *kill* ]]; then
backward-kill-word-match:      CUTBUFFER="$word$CUTBUFFER"
backward-kill-word-match-    else

kill-word-match-    if [[ -n $done || $LASTWIDGET = *kill* ]]; then
kill-word-match:      CUTBUFFER="$CUTBUFFER$word"
kill-word-match-    else

The kill widget replacements try to reproduce the builtin behavior of
building up the cutbuffer as they are called repeatedly.  If you use
widget names containing "kill" that are not supposed to have that
behavior, and then call through to those replacements, unexpected
things are going to happen.

You should also probably be selectively using one or both of -w and -f as in
  zle widgetname -w -f nolast
to change and/or restore LASTWIDGET when calling one widget from
inside another, so that actions that differ on the second and
successive repeated calls behave properly.