Problem with motion commands defined using match-word-by-style used with vi-delete

Problem with motion commands defined using match-word-by-style used with vi-delete

[Nikolai Weibull]

When a motion command defined using match-word-by-style, e.g.,
forward-word-match or backward-word-match, is used together with
vi-delete, they won't use the style assigned to the  command in
question.  The reason is that the $curcontext is set to zle:vi-delete,
not, for example, zle:forward-word-match.

It seems that this issue can be quite hard to fix, considering how
vi-delete is currently implemented.  But perhaps there's an easy
solution that I was unable to spot.

Until then I'm going to use my own vi-delete that uses
matach-word-by-style internally instead of whatever it uses by
default.  This allows me to define the rather useful text-object
motion-commands that Vim has, e.g., "daw" to delete a word.

  n.o.w.

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Bart Schaefer]

On Apr 22,  1:10am, Nikolai Weibull wrote:
}
} [...] $curcontext is set to zle:vi-delete, not, for example,
} zle:forward-word-match.
}
} It seems that this issue can be quite hard to fix, considering how
} vi-delete is currently implemented.  But perhaps there's an easy
} solution that I was unable to spot.

Try applying this same small change to each of the *-match functions:

--- 8< ---
@@ -3,7 +3,7 @@
 
 autoload match-words-by-style
 
-local curcontext=":zle:$WIDGET" word
+local curcontext=":zle:$WIDGETFUNC" word
 local -a matched_words
 integer count=${NUMERIC:-1}
 
--- 8< ---

I didn't actually try that because I'm not a vi mode user and I'm in
a hurry :-/ but it seems like it should do the trick.  If it doesn't,
try ${WIDGETFUNC%-match} instead.

} Until then I'm going to use my own vi-delete

Creating a vi-delete-match function seems like the next best thing.

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Nikolai Weibull]

On 4/22/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 22,  1:10am, Nikolai Weibull wrote:
> }
> } [...] $curcontext is set to zle:vi-delete, not, for example,
> } zle:forward-word-match.
> }
> } It seems that this issue can be quite hard to fix, considering how
> } vi-delete is currently implemented.  But perhaps there's an easy
> } solution that I was unable to spot.
>
> Try applying this same small change to each of the *-match functions:
>
> --- 8< ---
> @@ -3,7 +3,7 @@
>
>  autoload match-words-by-style
>
> -local curcontext=":zle:$WIDGET" word
> +local curcontext=":zle:$WIDGETFUNC" word
>  local -a matched_words
>  integer count=${NUMERIC:-1}
>
> --- 8< ---
>
> I didn't actually try that because I'm not a vi mode user and I'm in
> a hurry :-/ but it seems like it should do the trick.  If it doesn't,
> try ${WIDGETFUNC%-match} instead.

Hm, that sets curcontext to :zle:forward-word-match (or
:zle:forward-word), which means it won't be possible to use zstyles
anymore.

The following is what I'm using:

autoload -U forward-word-match
autoload -U backward-word-match
zle -N forward-parameter forward-word-match
zle -N backward-parameter backward-word-match
zstyle ':zle:forward-parameter' word-style shell
zstyle ':zle:backward-parameter' word-style shell
bindkey -a ")" forward-parameter
bindkey -a "(" backward-parameter

> } Until then I'm going to use my own vi-delete
>
> Creating a vi-delete-match function seems like the next best thing.

That's what I meant (I think) :-).

  nikolai

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Bart Schaefer]

On Apr 22,  1:04pm, Nikolai Weibull wrote:
}
} > +local curcontext=":zle:$WIDGETFUNC" word
} 
} Hm, that sets curcontext to :zle:forward-word-match (or
} :zle:forward-word), which means it won't be possible to use zstyles
} anymore.
} 
} The following is what I'm using:
} 
} zle -N forward-parameter forward-word-match
} zle -N backward-parameter backward-word-match

Oh, I see.  I didn't realize you meant you'd invented a completely new
widget name.  I assumed you were referring to e.g.

zle -N forward-word forward-word-match
zle -N backward-word backward-word-match

Note that you have to be careful (as you were) that the new names you
bind to {forward,backward}-word-match contain the corresponding string
"forward" or "backward", and that you always bind both of them.  If you
don't, negative values of $NUMERIC will cause errors.

} > } Until then I'm going to use my own vi-delete
} >
} > Creating a vi-delete-match function seems like the next best thing.
} 
} That's what I meant (I think) :-).

Yes, I was agreeing with you.

On further checking, however, the value of $WIDGETFUNC within the widget
called by vi-delete appears to be ".internal" which means that although
it's possible to determine *when* one of these functions has been called
from vi-delete, it's not possible to determine under which name it was
called.  So a custom vi-delete replacement appears to be required, and
perhaps we should consider adding one to the distribution.  The same is
going to be true of vi-change and any other widget that combines with a
motion widget in this way.

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Nikolai Weibull]

On 4/22/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 22,  1:04pm, Nikolai Weibull wrote:
> } > } Until then I'm going to use my own vi-delete
> } >
> } > Creating a vi-delete-match function seems like the next best thing.
> }
> } That's what I meant (I think) :-).
>
> Yes, I was agreeing with you.

Ah, :-).

> On further checking, however, the value of $WIDGETFUNC within the widget
> called by vi-delete appears to be ".internal" which means that although
> it's possible to determine *when* one of these functions has been called
> from vi-delete, it's not possible to determine under which name it was
> called.  So a custom vi-delete replacement appears to be required, and
> perhaps we should consider adding one to the distribution.  The same is
> going to be true of vi-change and any other widget that combines with a
> motion widget in this way.

I've begun writing one, but it won't work.  What I do is roughly the following:

vi-delete-match () {
  integer begin end

  local motion
  integer count=0
  read -k 1 motion
  while [[ $motion == [[:digit:]] ]]; do
    (( count = count * 10 + motion ))
    read -k 1 motion
  done
  (( count = (count == 0) ? 1 : count ))
  case $motion in
    (*)
      local motion_command="${${:-$(bindkey -a $motion)}##* }"
      if [[ -n $motion_command ]]; then
        (( begin = CURSOR ))
        zle $motion_command -n $count
        (( end = CURSOR + 1 ))
        (( CURSOR = begin ))
        BUFFER="${BUFFER[1,begin]}${BUFFER[end,-1]}"
      fi
      ;;
  esac
}
zle -N vi-delete-match

bindkey -a "d" vi-delete-match

The convoluted handling of $motion is for future expansion with what
Vim refers to as text objects, i.e., "aw" for "a word", which selects
the current word you're in.

This, however, doesn't work.  $WIDGET is set to vi-delete-match, which
is the top-level widget, not the widget run by the zle command in

        zle $motion_command -n $count

I guess this makes sense in almost all cases, but not here.

$WIDGETFUNC is set to vi-delete-match, which is correct, given the
value of $WIDGET.

I'm positive that there's a way to do this, but I can't see it, so any
help is welcome.

I'm sure it'll break all kinds of stuff, but one solution would be to
have getvirange() set bindk to k2 once it has been read and checked.

Also, it would be great if we had a switch for bindkey that made it
print the widgets name, nothing else.

  nikolai

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Bart Schaefer]

On Apr 22, 11:38pm, Nikolai Weibull wrote:
}
} I'm positive that there's a way to do this, but I can't see it, so any
} help is welcome.

In the short term, I think it'd work to reset $WIDGET yourself:

    local WIDGET=$motion_command
    zle $motion_command -n $count

} I'm sure it'll break all kinds of stuff, but one solution would be to
} have getvirange() set bindk to k2 once it has been read and checked.

I don't think that's sufficient.  getvirange() would have to fiddle with
saving and restoring some other state around the call to execzlefunc().

} Also, it would be great if we had a switch for bindkey that made it
} print the widgets name, nothing else.

It' be better if we had a $bindings associative array to go with $keymaps
and $widgets, and a zle function along the lines of recursive-edit except
it reads only one binding.  For example, it's rather messy to reimplement
describe-key-briefly in the shell:

  describe-key-briefly() {
    setopt localoptions extendedglob
    local -a bound rebound
    local b f=__-get-widget-name
    bindkey -N __ $KEYMAP
    bound=( ${${(f)"$(bindkey -M __ -L)"}/(#b)([^[:space:]]#)(#e)/__-$match} )
    rebound=( ${(u)bound##* } )
    function $f {
      zle -M "${(V)KEYS} is ${WIDGET#__-}"
      zle .accept-line	# end recursive-edit
    }
    for b in $rebound
    do
      zle -N $b $f
    done
    eval "${(j:;:)bound}"
    # Cf. read-from-minibuffer if you insist on having
    # correct cursor placement during this prompt
    zle -M "Describe key briefly: "
    zle .recursive-edit -K __
  }

This may suggest another way to implement vi-delete-match, though.  Hmm.

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Bart Schaefer]

On Apr 23, 10:57am, Nikolai Weibull wrote:
} Subject: Re: Problem with motion commands defined using match-word-by-styl
}
} > In the short term, I think it'd work to reset $WIDGET yourself:
} >
} >     local WIDGET=$motion_command
} >     zle $motion_command -n $count
} 
} WIDGET is, sadly, a read-only variable.

Declaring it "local" should circumvent that.  You might need "local -h",
now that I think of it.

} I fear my time would be
} better spent implementing .recursive-edit-read-one-key.

There must be a better name for it than that.  GNU emacs appears to call
it read-key-sequence.

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Nikolai Weibull]

On 4/23/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 23, 10:57am, Nikolai Weibull wrote:
> } WIDGET is, sadly, a read-only variable.
>
> Declaring it "local" should circumvent that.  You might need "local -h",
> now that I think of it.

Doesn't help.

> } I fear my time would be
> } better spent implementing .recursive-edit-read-one-key.
>
> There must be a better name for it than that.  GNU emacs appears to call
> it read-key-sequence.
>

Definitely better :-).

  nikolai

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Peter Stephenson]

Bart Schaefer wrote:
> } I fear my time would be
> } better spent implementing .recursive-edit-read-one-key.
> 
> There must be a better name for it than that.  GNU emacs appears to call
> it read-key-sequence.

Here's a simple internal widget that reads a key sequence and sets
REPLY to the command bound to it (so you can run zle on that).  The key
sequence reading is just like normal operation, so you can even use M-x.
I think this is better than reading just the key sequence, but no doubt
you'll let me know if this doesn't do the job.  It's so easy to
implement I'll commit it anyway.  (I called it read-command because a
command is what you get back, but pedantically it ought to be something
like read-key-sequence-and-return-command; that didn't seem very memorable.)

You need to use it something like:

  local REPLY
  
  if zle read-command && [[ $REPLY != undefined-key ]]; then
      zle $REPLY
      zle -M "I just executed $REPLY!"
  else
      zle -M "No such command"
  fi

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.51
diff -u -r1.51 zle.yo
--- Doc/Zsh/zle.yo	21 Mar 2006 19:19:15 -0000	1.51
+++ Doc/Zsh/zle.yo	23 Apr 2006 23:06:56 -0000
@@ -103,6 +103,12 @@
 detect loops the process will be stopped if there are twenty such replacements
 without a real command being read.
 
+A key sequence typed by the user can be turned into a command name for use
+in user-defined widgets with the tt(read-command) widget, described
+ifzman(below)\
+ifnzman(in noderef(Miscellaneous) below)\
+.
+
 texinode(Zle Builtins)(Zle Widgets)(Keymaps)(Zsh Line Editor)
 sect(Zle Builtins)
 cindex(zle, builtin commands)
@@ -1767,6 +1773,16 @@
 construct into the editor buffer.
 The latter is equivalent to tt(push-input) followed by tt(get-line).
 )
+tindex(read-command)
+item(tt(read-command))(
+Only useful from a user-defined widget.  A keystroke is read just as in
+normal operation, but instead of the command being executed the name
+of the command that would be executed is stored in the shell parameter
+tt(REPLY).  This can be used as the argument of a future tt(zle)
+command.  If the key sequence is not bound, status 1 is returned;
+typically, however, tt(REPLY) is set to tt(undefined-key) to indicate
+a useless key sequence.
+)
 tindex(recursive-edit)
 item(tt(recursive-edit))(
 Only useful from a user-defined widget.  At this point in the function,
Index: Src/Zle/iwidgets.list
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/iwidgets.list,v
retrieving revision 1.8
diff -u -r1.8 iwidgets.list
--- Src/Zle/iwidgets.list	24 Nov 2005 10:25:34 -0000	1.8
+++ Src/Zle/iwidgets.list	23 Apr 2006 23:06:56 -0000
@@ -86,6 +86,7 @@
 "quoted-insert", quotedinsert, ZLE_MENUCMP | ZLE_KEEPSUFFIX
 "quote-line", quoteline, 0
 "quote-region", quoteregion, 0
+"read-command", readcommand, 0
 "recursive-edit", recursiveedit, ZLE_MENUCMP | ZLE_KEEPSUFFIX | ZLE_LASTCOL
 "redisplay", redisplay, ZLE_MENUCMP | ZLE_KEEPSUFFIX | ZLE_LASTCOL
 "redo", redo, ZLE_KEEPSUFFIX
Index: Src/Zle/zle_keymap.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_keymap.c,v
retrieving revision 1.24
diff -u -r1.24 zle_keymap.c
--- Src/Zle/zle_keymap.c	28 Jan 2006 15:02:26 -0000	1.24
+++ Src/Zle/zle_keymap.c	23 Apr 2006 23:06:57 -0000
@@ -1441,3 +1441,16 @@
 	return;
     linkkeymap(km, "main", 0);
 }
+
+/**/
+mod_export int
+readcommand(UNUSED(char **args))
+{
+    Thingy thingy = getkeycmd();
+
+    if (!thingy)
+	return 1;
+
+    setsparam("REPLY", ztrdup(thingy->nam));
+    return 0;
+}

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Nikolai Weibull]

On 4/24/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> Bart Schaefer wrote:
> > } I fear my time would be
> > } better spent implementing .recursive-edit-read-one-key.
> >
> > There must be a better name for it than that.  GNU emacs appears to call
> > it read-key-sequence.
>
> Here's a simple internal widget that reads a key sequence and sets
> REPLY to the command bound to it (so you can run zle on that).

Seems to work just fine.  It does, however, only solve part of the
problem.  There's still no easy way to execute the command in the
right environment so that WIDGET is set to the read command that we
want to execute.

  nikolai

Re: Problem with motion commands defined using match-word-by-style used with vi-delete

[Bart Schaefer]

On Apr 24,  9:39pm, Nikolai Weibull wrote:
} Subject: Re: Problem with motion commands defined using match-word-by-styl
}
} On 4/24/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
} >
} > Here's a simple internal widget that reads a key sequence and sets
} > REPLY to the command bound to it (so you can run zle on that).

[Hmm, somehow I managed to miss PWS's message.  I wonder if it was a
victim of Verizon's latest overeager spam-blocking fiasco.]

This is actually quite useful as it resets KEYS as well as sets REPLY,
so with this you can do

    describe-key-briefly() {
      zle -R "Describe key briefly: "
      zle read-command
      zle -M "${(V)KEYS} is $REPLY"
    }

That doesn't help with describe-binding, which needs to map in the
other direction, but it's a start.

Incidentally I just noticed that within a widget called by using
execute-named-command, the value of $KEYS is carriage return.  I'm not
sure what I expected it to be, but that wasn't it.

} There's still no easy way to execute the command in the right
} environment so that WIDGET is set to the read command that we want to
} execute.

It really *should* be the case that

    local -h WIDGET

creates a new parameter named WIDGET that is neither read-only nor
special, but apparently the usual parameter rules don't apply to the
ZLE specials.