Overriding a yank* widget in zle

Overriding a yank* widget in zle

[Wayne Davison]

[-- Attachment #1.1: Type: text/plain, Size: 544 bytes --]

I'm trying to figure out how to override the zle yank widget without
breaking the ability to use yank-pop, and this does not appear to be
possible in the current code.  A query in early 2005 on the subject went
unanswered, so hopefully I didn't miss some simple solution to this.

I've coded up a patch that adds the -y option to zle so that I can define a
"zle -Ny yank" widget (as well as yank-pop), which marks it as being a
ZLE_YANK equivalent.  I'm not sure that this is the right solution, so see
what you think of the change.

..wayne..

[-- Attachment #1.2: Type: text/html, Size: 625 bytes --]

Re: Overriding a yank* widget in zle

[Wayne Davison]

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

On Thu, Dec 30, 2010 at 1:59 PM, Wayne Davison <wayned@users.sourceforge.net
> wrote:

> I've coded up a patch that adds the -y option to zle
>

Looks like the mailing list ate my patch attachment, so I uploaded it here:

http://opencoder.net/zle-yank-opt.patch

..wayne..

Re: Overriding a yank* widget in zle

[Bart Schaefer]

On Dec 30,  1:59pm, Wayne Davison wrote:
} 
} I've coded up a patch that adds the -y option to zle so that I can define a
} "zle -Ny yank" widget (as well as yank-pop), which marks it as being a
} ZLE_YANK equivalent.

This sort of follows from "zle -C".  For completion widgets, it was
recognized that there are a set of behaviors which are the model for
any newly-added widget, and the builtin completion widgets provide
names for those behaviors.

Perhaps a general solution would be that for *any* widget, not just
a completion one, it should be possible to name a "prototype" widget
whose behavior the new widget is intended to simulate or replace.
"zle -P WIDGET PROTOTYPE-WIDGET [FUNCTION]" where "zle -N ..." becomes
a special case equivalent to "zle -P WIDGET self-insert FUNCTION",
or something to that effect (or maybe undefined-key instead).

Then one could write, e.g.,

  zle -P history-search-sideways history-incremental-search-forward

and zle would "know" to invoke the minibuffer and re-call the function
as each new keystroke is typed, without that needing to be coded as a
loop in the widget itself.

Then the question would be whether we still need "zle -C ..." other
than for backward compatibility.

The only other solution to this that I've thought of would be to follow
the example of the auto-suffix-remove and auto-suffix-retain widgets,
that is, have a special widget whose only effect is to have the side-
effect of enabling yank-pop on the next interaction: yank-pop-enable
perhaps (is yank-pop-disable ever needed?).

Re: Overriding a yank* widget in zle

[Wayne Davison]

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

On Fri, Dec 31, 2010 at 12:28 AM, Bart Schaefer
<schaefer@brasslantern.com>wrote:

> Perhaps a general solution would be that for *any* widget, not just a
> completion one, it should be possible to name a "prototype" widget whose
> behavior the new widget is intended to simulate or replace.
>

That seems like a great solution to me.

The only other solution to this that I've thought of would be to follow the
> example of the auto-suffix-remove and auto-suffix-retain widgets, that is,
> have a special widget whose only effect is to have the side-effect of
> enabling yank-pop on the next interaction: yank-pop-enable perhaps (is
> yank-pop-disable ever needed?).
>

Something like that would work if done right.  I tried something along those
lines (it was named "yank-noop"), but hadn't worked out the right bits to
make the flags stick around long enough before I changed direction.  I like
the prototype idiom best, though.

..wayne..

PATCH: Implement zle -P

[Mikael Magnusson]

This lets you say
% zle -P mywidget prototypewidget myfunction
and it will work like zle -N mywidget myfunction except it will behave
like prototypewidget in Various Ways™.

---

I haven't tested this much (for completion functions, not at all) yet,
but it works for the case in the current thread, see example at the
bottom. Does it look overall sane? I'm not very sure on which/how/where
all these flags are checked and set. The final argument should probably
be optional and default to the first, like for zle -N, but zle -C doesn't
seem to do that, and that's the code I mostly copied.

I don't see any reason to change zle -N to call into zle -P internally though.

% zle -P myyank yank myyank
% myyank () {
    zle -M hello
    local oldbuf=$CUTBUFFER CUTBUFFER=${(U)CUTBUFFER
    zle .yank
    CUTBUFFER=$oldbuf
}
  # put asdfdδ in the cutbuffer here
  # press yank and myyank alternatingly
% asdfdδASDFDΔASDFDΔASDFDΔasdfdδasdfdδasdfdδASDFDΔASDFDΔASDFDΔ
  # each word gets highlighted appropriately in both cases

 Src/Zle/zle_main.c   |  5 +++--
 Src/Zle/zle_thingy.c | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index c1b70e7..d4592ba 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -1396,7 +1396,8 @@ execzlefunc(Thingy func, char **args, int set_bindk)
 	    opts[XTRACE] = oxt;
 	    sfcontext = osc;
 	    endparamscope();
-	    lastcmd = 0;
+	    if (!(w->flags & ZLE_NOTCOMMAND))
+		lastcmd = w->flags;
 	    r = 1;
 	    redup(osi, 0);
 	}
@@ -1975,7 +1976,7 @@ zle_main_entry(int cmd, va_list ap)
 static struct builtin bintab[] = {
     BUILTIN("bindkey", 0, bin_bindkey, 0, -1, 0, "evaM:ldDANmrsLRp", NULL),
     BUILTIN("vared",   0, bin_vared,   1,  1, 0, "aAcef:hi:M:m:p:r:t:", NULL),
-    BUILTIN("zle",     0, bin_zle,     0, -1, 0, "aAcCDFgGIKlLmMNrRTUw", NULL),
+    BUILTIN("zle",     0, bin_zle,     0, -1, 0, "aAcCDFgGIKlLmMNPrRTUw", NULL),
 };
 
 /* The order of the entries in this table has to match the *HOOK
diff --git a/Src/Zle/zle_thingy.c b/Src/Zle/zle_thingy.c
index 7fd3a59..e648838 100644
--- a/Src/Zle/zle_thingy.c
+++ b/Src/Zle/zle_thingy.c
@@ -347,6 +347,7 @@ bin_zle(char *name, char **args, Options ops, UNUSED(int func))
 	{ 'A', bin_zle_link, 2,  2 },
 	{ 'N', bin_zle_new,  1,  2 },
 	{ 'C', bin_zle_complete, 3, 3 },
+	{ 'P', bin_zle_prototype, 3, 3},
 	{ 'R', bin_zle_refresh, 0, -1 },
 	{ 'M', bin_zle_mesg, 1, 1 },
 	{ 'U', bin_zle_unget, 1, 1 },
@@ -591,6 +592,42 @@ bin_zle_new(char *name, char **args, UNUSED(Options ops), UNUSED(char func))
 
 /**/
 static int
+bin_zle_prototype(char *name, char **args, UNUSED(Options ops), UNUSED(char func))
+{
+    Thingy t;
+    Widget w, pw;
+
+    t = rthingy((args[1][0] == '.') ? args[1] : dyncat(".", args[1]));
+    pw = t->widget;
+    unrefthingy(t);
+
+    if (!pw) {
+	zwarnnam(name, "invalid widget `%s'", args[1]);
+	return 1;
+    }
+    w = zalloc(sizeof(*w));
+    w->flags = pw->flags & ~WIDGET_INT;
+    w->first = NULL;
+    if (w->flags & WIDGET_NCOMP) {
+	w->u.comp.fn = pw->u.fn;
+	w->u.comp.wid = ztrdup(args[1]);
+	w->u.comp.func = ztrdup(args[2]);
+    } else {
+	w->u.fnnam = ztrdup(args[2]);
+    }
+    if (bindwidget(w, rthingy(args[0]))) {
+	freewidget(w);
+	zwarnnam(name, "widget name `%s' is protected", args[0]);
+	return 1;
+    }
+    if (w->flags & WIDGET_NCOMP)
+	hascompwidgets++;
+
+    return 0;
+}
+
+/**/
+static int
 bin_zle_complete(char *name, char **args, UNUSED(Options ops), UNUSED(char func))
 {
     Thingy t;
-- 
2.5.0

Re: PATCH: Implement zle -P

[Mikael Magnusson]

On Mon, Aug 31, 2015 at 9:54 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> This lets you say
> % zle -P mywidget prototypewidget myfunction
> and it will work like zle -N mywidget myfunction except it will behave
> like prototypewidget in Various Ways™.
>
> ---
>
> I haven't tested this much (for completion functions, not at all) yet,
> but it works for the case in the current thread, see example at the
> bottom. Does it look overall sane? I'm not very sure on which/how/where
> all these flags are checked and set. The final argument should probably
> be optional and default to the first, like for zle -N, but zle -C doesn't
> seem to do that, and that's the code I mostly copied.
>
> I don't see any reason to change zle -N to call into zle -P internally though.

Here's the original thread, by the way.
http://www.zsh.org/mla/workers/2010/msg01000.html

-- 
Mikael Magnusson

PATCH: Set completion function flags correctly for zle -P

[Mikael Magnusson]

---

This appears to work better.

 Src/Zle/zle_thingy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Src/Zle/zle_thingy.c b/Src/Zle/zle_thingy.c
index e648838..0401099 100644
--- a/Src/Zle/zle_thingy.c
+++ b/Src/Zle/zle_thingy.c
@@ -606,9 +606,10 @@ bin_zle_prototype(char *name, char **args, UNUSED(Options ops), UNUSED(char func
 	return 1;
     }
     w = zalloc(sizeof(*w));
-    w->flags = pw->flags & ~WIDGET_INT;
+    w->flags = pw->flags & ~(WIDGET_INT|ZLE_ISCOMP);
     w->first = NULL;
-    if (w->flags & WIDGET_NCOMP) {
+    if (pw->flags & ZLE_ISCOMP) {
+	w->flags |= WIDGET_NCOMP;
 	w->u.comp.fn = pw->u.fn;
 	w->u.comp.wid = ztrdup(args[1]);
 	w->u.comp.func = ztrdup(args[2]);
-- 
2.5.0

Re: PATCH: Set completion function flags correctly for zle -P

[Mikael Magnusson]

On Mon, Aug 31, 2015 at 11:55 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> ---
>
> This appears to work better.
>
>  Src/Zle/zle_thingy.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Src/Zle/zle_thingy.c b/Src/Zle/zle_thingy.c
> index e648838..0401099 100644
> --- a/Src/Zle/zle_thingy.c
> +++ b/Src/Zle/zle_thingy.c
> @@ -606,9 +606,10 @@ bin_zle_prototype(char *name, char **args, UNUSED(Options ops), UNUSED(char func
>         return 1;
>      }
>      w = zalloc(sizeof(*w));
> -    w->flags = pw->flags & ~WIDGET_INT;
> +    w->flags = pw->flags & ~(WIDGET_INT|ZLE_ISCOMP);
>      w->first = NULL;
> -    if (w->flags & WIDGET_NCOMP) {
> +    if (pw->flags & ZLE_ISCOMP) {
> +       w->flags |= WIDGET_NCOMP;
>         w->u.comp.fn = pw->u.fn;
>         w->u.comp.wid = ztrdup(args[1]);
>         w->u.comp.func = ztrdup(args[2]);

Here's the final(?) touchup, not counting documentation. It makes the
last argument optional. Maybe it would be better to make the middle
argument optional? Not sure. (This one will be whitespace damaged.)

I can now do this (which is why I originally found this old thread, if
anyone was curious):

function _start_paste() {
  local content
  local a b
  local oldcutbuf="$CUTBUFFER"
  # I haven't quite decided how I want to control quoting yet.
  [[ $_SPACE_AFTER_PASTE_QUOTE = 1 ]]; a=$?
  (( $+NUMERIC )) || [[ $KEYS = $'\e\e'* ]]; b=$?
  zle .$WIDGET -N content
  if [[ $a -ne $b ]]; then
    CUTBUFFER=${(q-)content}' '
  else
    CUTBUFFER=$content
  fi
  zle .yank
  CUTBUFFER="$oldcutbuf"
}
zle -P bracketed-paste bracketed-paste _start_paste

And my pastes are appropriately highlit. (Wouldn't it really be more
useful to have the middle argument optional? I see how it might be
confusing if you're used to the zle -N behavior though.)

diff --git i/Src/Zle/zle_thingy.c w/Src/Zle/zle_thingy.c
index 8c66761..20a1de9 100644
--- i/Src/Zle/zle_thingy.c
+++ w/Src/Zle/zle_thingy.c
@@ -347,7 +347,7 @@ bin_zle(char *name, char **args, Options ops,
UNUSED(int func))
        { 'A', bin_zle_link, 2,  2 },
        { 'N', bin_zle_new,  1,  2 },
        { 'C', bin_zle_complete, 3, 3 },
-       { 'P', bin_zle_prototype, 3, 3},
+       { 'P', bin_zle_prototype, 2, 3},
        { 'R', bin_zle_refresh, 0, -1 },
        { 'M', bin_zle_mesg, 1, 1 },
        { 'U', bin_zle_unget, 1, 1 },
@@ -596,6 +596,7 @@ bin_zle_prototype(char *name, char **args,
UNUSED(Options ops), UNUSED(char func
 {
     Thingy t;
     Widget w, pw;
+    char *funcname = args[2] ? args[2] : args[0];

     t = rthingy((args[1][0] == '.') ? args[1] : dyncat(".", args[1]));
     pw = t->widget;
@@ -618,9 +619,9 @@ bin_zle_prototype(char *name, char **args,
UNUSED(Options ops), UNUSED(char func
        w->flags |= WIDGET_NCOMP;
        w->u.comp.fn = pw->u.fn;
        w->u.comp.wid = ztrdup(args[1]);
-       w->u.comp.func = ztrdup(args[2]);
+       w->u.comp.func = ztrdup(funcname);
     } else {
-       w->u.fnnam = ztrdup(args[2]);
+       w->u.fnnam = ztrdup(funcname);
     }
     if (bindwidget(w, rthingy(args[0]))) {
        freewidget(w);


-- 
Mikael Magnusson

Re: PATCH: Implement zle -P

[Peter Stephenson]

On Mon, 31 Aug 2015 09:54:02 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> This lets you say
> % zle -P mywidget prototypewidget myfunction
> and it will work like zle -N mywidget myfunction except it will behave
> like prototypewidget in Various Ways™.

It's not entirely clear what this does without documentation, but as the
flags are a bit obcsure anyway, it might not be all that clear how to
document it, either.

pws

Re: PATCH: Implement zle -P

[Bart Schaefer]

On Aug 31,  6:11pm, Peter Stephenson wrote:
} Subject: Re: PATCH: Implement zle -P
}
} On Mon, 31 Aug 2015 09:54:02 +0200
} Mikael Magnusson <mikachu@gmail.com> wrote:
} > This lets you say
} > % zle -P mywidget prototypewidget myfunction
} > and it will work like zle -N mywidget myfunction except it will behave
} > like prototypewidget in Various Ways0x2122.
} 
} It's not entirely clear what this does without documentation, but as the
} flags are a bit obcsure anyway, it might not be all that clear how to
} document it, either.

I presume this is exactly like "zle -C name widget function" except that
"widget" doesn't have to be a completion widget and "function" defaults
to being the same as "name".

Presumably the idea is for wrapper widgets, e.g., something like this:

    zle -P bracketed-paste-magic bracketed-paste

which would then make b-p-magic behave exactly like b-p, and thereby,
e.g., eliminate the need for this stuff at the end of the former:

    # Arrange to display highlighting if necessary
    if [[ -n ${(M)zle_highlight:#paste:*} ]]; then
        zle -R
        zle .read-command && zle -U - $KEYS
    fi

If that's NOT what it accomplishes, then I'm uncertain why it's needed
at all.

Re: PATCH: Implement zle -P

[Mikael Magnusson]

On Tue, Sep 1, 2015 at 8:23 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 31,  6:11pm, Peter Stephenson wrote:
> } Subject: Re: PATCH: Implement zle -P
> }
> } On Mon, 31 Aug 2015 09:54:02 +0200
> } Mikael Magnusson <mikachu@gmail.com> wrote:
> } > This lets you say
> } > % zle -P mywidget prototypewidget myfunction
> } > and it will work like zle -N mywidget myfunction except it will behave
> } > like prototypewidget in Various Ways0x2122.
> }
> } It's not entirely clear what this does without documentation, but as the
> } flags are a bit obcsure anyway, it might not be all that clear how to
> } document it, either.
>
> I presume this is exactly like "zle -C name widget function" except that
> "widget" doesn't have to be a completion widget and "function" defaults
> to being the same as "name".
>
> Presumably the idea is for wrapper widgets, e.g., something like this:
>
>     zle -P bracketed-paste-magic bracketed-paste
>
> which would then make b-p-magic behave exactly like b-p, and thereby,
> e.g., eliminate the need for this stuff at the end of the former:
>
>     # Arrange to display highlighting if necessary
>     if [[ -n ${(M)zle_highlight:#paste:*} ]]; then
>         zle -R
>         zle .read-command && zle -U - $KEYS
>     fi
>
> If that's NOT what it accomplishes, then I'm uncertain why it's needed
> at all.

Well, it was your idea in the first place. And yeah, I made a mess of
these threads, there's an example for the above in the latest mail.

-- 
Mikael Magnusson