zle oddity or some option running wild?

zle oddity or some option running wild?

[Thomas Lauer]

Hi all,

I am building zle user-defined widgets with great success (and almost
running out of Alt/Ctrl etc combos :-/). Now though I've run into a
strange effect which I don't understand.

I have this in my zsh init:
autoload -U select-word-style
select-word-style shell
zle -N backward-kill-shell-word backward-kill-word
zstyle :zle:backward-kill-shell-word word-style shell

and have backward-kill-shell-word bound to Ctrl-A to test. This is what
happens if I try to use that shortcut with a line that contains just
$ test test1<CURSOR><Ctrl-A>

This turns the line into
$ test <CURSOR>

If I press Ctrl-Y (my shortcut for yank) I get
$ test test test1<CURSOR>

If I add a test widget that just calls backward-kill-shell-word and then
prints the actual $CUTBUFFER this is indeed "test test1" although
backward-kill-shell-word has only removed "test1" from the command line.

This is probably due to yet another strange option buried somewhere in
my init... speaking of which, my
WORDCHARS='`!"£$%^&*-_=+;:''@#~\\<>?'

All this with:
1/ram>zsh --version
zsh 5.9 (x86_64-debian-linux-gnu)

I am puzzled and grateful for any idea how to fix this.

Thomas

Re: zle oddity or some option running wild?

[Thomas Lauer]

From: Thomas Lauer <thomas.lauer@virgin.net>
Date: Wed, 26 Jun 2024 17:10:58 +0100

Just discovered a typo :-( see below.

> I have this in my zsh init:
> autoload -U select-word-style
> select-word-style shell
> zle -N backward-kill-shell-word backward-kill-word

This line is actually:
zle -N backward-kill-shell-word backward-kill-word-match

Somehow the "-match" part got lost...

> Thomas

Re: zle oddity or some option running wild?

[Thomas Lauer]

From: Thomas Lauer <thomas.lauer@virgin.net>
Date: Wed, 26 Jun 2024 17:10:58 +0100

> I have this in my zsh init:
> autoload -U select-word-style
> select-word-style shell

I've now realised that these two commands interfere with almost every
widget I've written that copies/kills stuff from the command line. No
parameter for "select-word-style" makes these work again.

So I assume this function is broken and I removed those lines...

> zle -N backward-kill-shell-word backward-kill-word
> zstyle :zle:backward-kill-shell-word word-style shell

... as well as these two.

I'll look into creating a backward-kill-shell-word widget by other
means.

> Thomas

Re: zle oddity or some option running wild?

[Peter Stephenson]

> On 27/06/2024 16:19 BST Thomas Lauer <thomas.lauer@virgin.net> wrote:
> From: Thomas Lauer <thomas.lauer@virgin.net>
> Date: Wed, 26 Jun 2024 17:10:58 +0100
> 
> > I have this in my zsh init:
> > autoload -U select-word-style
> > select-word-style shell
> 
> I've now realised that these two commands interfere with almost every
> widget I've written that copies/kills stuff from the command line.

This is likely to be something to do with the "zle -f" stuff documented
in the zshzle manual page --- getting kills and yanks from widgets to
fit together nicely is a bit messy because they don't have the same
knowledge about what's going on as builtin widgets.

pws

Re: zle oddity or some option running wild?

[Thomas Lauer]

From: Peter Stephenson <p.w.stephenson@ntlworld.com>
Date: Thu, 27 Jun 2024 16:41:50 +0100 (BST)

> > On 27/06/2024 16:19 BST Thomas Lauer <thomas.lauer@virgin.net> wrote:
> > From: Thomas Lauer <thomas.lauer@virgin.net>
> > Date: Wed, 26 Jun 2024 17:10:58 +0100
> > 
> > > I have this in my zsh init:
> > > autoload -U select-word-style
> > > select-word-style shell
> > 
> > I've now realised that these two commands interfere with almost every
> > widget I've written that copies/kills stuff from the command line.
> 
> This is likely to be something to do with the "zle -f" stuff documented
> in the zshzle manual page --- getting kills and yanks from widgets to
> fit together nicely is a bit messy because they don't have the same
> knowledge about what's going on as builtin widgets.
> 
> pws

Whatever the cause, select-word-style seems to change something globally
in a way that isn't helpful (to my use case).

But I've now cobbled together something that seems to do the job of
backward-kill-shell-word. A bit of a hack but seems to work:

backward-kill-shell-word() {
	mark-or-kill
	zle vi-backward-blank-word
	mark-or-kill
}

with

mark-or-kill() {
	if [[ $REGION_ACTIVE == 0 ]]; then
		zle set-mark-command
	else
		zle set-mark-command -n -1
		zle kill-region
	fi
}

(I had the latter already defined as I use it for various other
widgets.)

So problem solved w/o select-word-style and lesson learned :-/

Thomas

Re: zle oddity or some option running wild?

[Bart Schaefer]

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.

Re: zle oddity or some option running wild?

[Thomas Lauer]

From: Bart Schaefer <schaefer@brasslantern.com>
Date: Thu, 27 Jun 2024 21:35:45 -0700

> 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.

If I am trying to use some third-party stuff whose inner workings I
don't really fully understand and it doesn't work OOTB then I tend to
move on. All the more since the solution I outlined earlier is, though
by no means perfect*, "good enough" for my use case.

* vi-backward-blank-word simply stops after the first blank, so an
argument with blanks (ie a pathname) will not work with my quick fix. I
avoid blanks in file/pathnames like the plague so it's not much of a
problem for me but it's clearly not a general solution. And I do think
that a set of functions that works well with what the shell sees as a
single argument:

$>touch Test\ Directory
$>touch "Test Directory"

even if it contains funny characters would be nice to have. So maybe
I'll look into select-word-style, time permitting.

Thomas