PATCH: Add $OVERSTRIKE in zle widgets

PATCH: Add $OVERSTRIKE in zle widgets

[Frank Terbeck]

I recently started using vi mode in zle. I'm dynamically setting
$psvar[1] to either "i" or "c" and use `reset-prompt' to redraw the
prompt via `zle-keymap-select'.

I wanted to have "r" displayed if `vi-replace' was used to put zle in
overstrike mode. I couldn't come up with an easy solution, though.

This adds a read-only integer parameter `$OVERSTRIKE' to the set of
special parameters available in zle-widgets. Since `zle-keymap-select'
is a widget, it has access to the parameter. That makes it trivial to
set $psvar[1] to "r" if zle is in overstrike mode.


Do others think that's useful enough to have in zsh?

Regards, Frank
---
 Doc/Zsh/zle.yo       |    4 ++++
 Src/Zle/zle_params.c |   10 ++++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 0e2fea5..a1a5092 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -754,6 +754,10 @@ called with the tt(zle) builtin command will use the value
 assigned. If it is unset inside a widget function, builtin widgets
 called behave as if no numeric argument was given.
 )
+vindex(OVERSTRIKE)
+item(tt(OVERSTRIKE) (integer))(
+Non-zero if tt(zle) is in overstrike mode; zero otherwise.  Read-only.
+)
 vindex(PENDING)
 item(tt(PENDING) (integer))(
 The number of bytes pending for input, i.e. the number of bytes which have
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index 2883c0f..2c598f1 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -87,6 +87,8 @@ static const struct gsu_integer mark_gsu =
 { get_mark, set_mark, zleunsetfn };
 static const struct gsu_integer numeric_gsu =
 { get_numeric, set_numeric, unset_numeric };
+static const struct gsu_integer overstrike_gsu =
+{ get_overstrike, NULL, zleunsetfn };
 static const struct gsu_integer pending_gsu =
 { get_pending, NULL, zleunsetfn };
 static const struct gsu_integer region_active_gsu =
@@ -124,6 +126,7 @@ static struct zleparam {
     { "LBUFFER", PM_SCALAR,  GSU(lbuffer_gsu), NULL },
     { "MARK",  PM_INTEGER, GSU(mark_gsu), NULL },
     { "NUMERIC", PM_INTEGER | PM_UNSET, GSU(numeric_gsu), NULL },
+    { "OVERSTRIKE", PM_INTEGER | PM_READONLY, GSU(overstrike_gsu), NULL },
     { "PENDING", PM_INTEGER | PM_READONLY, GSU(pending_gsu), NULL },
     { "POSTDISPLAY", PM_SCALAR, GSU(postdisplay_gsu), NULL },
     { "PREBUFFER",  PM_SCALAR | PM_READONLY,  GSU(prebuffer_gsu), NULL },
@@ -459,6 +462,13 @@ get_bufferlines(UNUSED(Param pm))
 
 /**/
 static zlong
+get_overstrike(UNUSED(Param pm))
+{
+    return !insmode;
+}
+
+/**/
+static zlong
 get_pending(UNUSED(Param pm))
 {
     return noquery(0);
-- 
1.7.2.rc2

Re: PATCH: Add $OVERSTRIKE in zle widgets

[Peter Stephenson]

On Tue,  3 Aug 2010 02:57:33 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> This adds a read-only integer parameter `$OVERSTRIKE' to the set of
> special parameters available in zle-widgets. Since `zle-keymap-select'
> is a widget, it has access to the parameter. That makes it trivial to
> set $psvar[1] to "r" if zle is in overstrike mode.
> 
> 
> Do others think that's useful enough to have in zsh?

One think I'd suggest is using OVERWRITE instead of OVERSTRIKE, since
that's what the corresponding zle widget is called; there's no use of
"overstrike" in the documentation at present, and it vaguely suggests to me
a visual effect such as two characters on top of one another or a line
through.  You might also want to refer to the overwrite-mode widget.

Apart from that, this looks useful; the only thing that might make a
difference is if there was some other information that could be combined
with this and the result presented in a more compact way, such as a set of
flags in a single variable.  However, I can't think of anything that would
fit that bill, and the code is minimal anyway.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: Add $OVERSTRIKE in zle widgets

[Frank Terbeck]

Peter Stephenson wrote:
> On Tue,  3 Aug 2010 02:57:33 +0200
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> This adds a read-only integer parameter `$OVERSTRIKE' to the set of
>> special parameters available in zle-widgets. Since `zle-keymap-select'
>> is a widget, it has access to the parameter. That makes it trivial to
>> set $psvar[1] to "r" if zle is in overstrike mode.
>> 
>> 
>> Do others think that's useful enough to have in zsh?
>
> One think I'd suggest is using OVERWRITE instead of OVERSTRIKE, since
> that's what the corresponding zle widget is called; there's no use of
> "overstrike" in the documentation at present, and it vaguely suggests to me
> a visual effect such as two characters on top of one another or a line
> through.  You might also want to refer to the overwrite-mode widget.

Okay, will change that.


> Apart from that, this looks useful; the only thing that might make a
> difference is if there was some other information that could be combined
> with this and the result presented in a more compact way, such as a set of
> flags in a single variable.  However, I can't think of anything that would
> fit that bill, and the code is minimal anyway.

One thing, that may make sense would be to signal whether or nor a
mini-buffer is active or not. When switching to a mini-buffer (with
`execute-named-cmd' for example) the $KEYMAP in `zle-keymap-select()'
is "viins". But - the way I understand it - there are really only a few
key bindings are available in a mini-buffer. So, it would make sense to
be able to display that state accordingly.

I didn't look into where to get that information from yet.

How would you organise that information? In a string, where multiple
characters would signify different states? Like ZLE_STATE='mo' meaning
overwrite mode and a mini-buffer is active.

Or would you be using an associative array where we'd set key value
pairs like zle_state[overwrite]=1 and zle_state[mini-buffer]=1?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: Add $OVERSTRIKE in zle widgets

[Peter Stephenson]

On Tue, 03 Aug 2010 11:44:06 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> How would you organise that information? In a string, where multiple
> characters would signify different states? Like ZLE_STATE='mo' meaning
> overwrite mode and a mini-buffer is active.

That's the kind of thing I had in mind, but strings are cheap nowadays, and
[[ ... ]] tests natural in the shell, so you might just it make it verbose
and contain "insert", "overwrite", "minibuffer insert", "minibuffer
overwrite", and test '[[ $ZLE_STATE = *overwrite* ]]', which is completely
unambiguous while the speed penalty is unnoticeable.  Use of this idiom
makes it easy to upgrade the variable in a backward compatible way and
without variable namespace pollution.

I think the "minibuffer", such as it is, is tied to the "statusline"
variable. Some of the code associated with that is a bit grungy (yes, I
know, you're astonished), but mostly I think that's down to how the
minibuffer is generated rather than whether or how it's displayed.

Similarly, there's also "listshown" which relates to whether completion
lists are being displayed, which is somehow related to "showinglist".
Code associated with that is, er, completion code.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck]

This is the $OVERWRITE idea converted to a string $ZLE_STATE, that may
contain more than one attribute. Currently it only handles the status of
the overwrite bit (!insmode).
---
 Doc/Zsh/zle.yo       |    7 +++++++
 Src/Zle/zle_params.c |   22 ++++++++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 0e2fea5..ab5ea3f 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -854,6 +854,13 @@ executed; the second argument that followed tt(zle -C) when the widget was
 defined.  This is the name of a builtin completion widget.  For widgets
 defined with tt(zle -N) this is set to the empty string.  Read-only.
 )
+vindex(ZLE_STATE)
+item(tt(ZLE_STATE) (scalar))(
+Contains a set of sub-strings that describe the current tt(zle) state.
+Currently, this can only contain `tt(overwrite)' which is the case if
+tt(zle) will overwrite existing characters if the cursor is not at the
+end of a buffer line and new characters are entered.  Read-only.
+)
 enditem()
 
 subsect(Special Widgets)
diff --git a/Src/Zle/zle_params.c b/Src/Zle/zle_params.c
index 2883c0f..ee8814d 100644
--- a/Src/Zle/zle_params.c
+++ b/Src/Zle/zle_params.c
@@ -76,6 +76,8 @@ static const struct gsu_scalar widgetfunc_gsu =
 { get_widgetfunc, nullstrsetfn, zleunsetfn };
 static const struct gsu_scalar widgetstyle_gsu =
 { get_widgetstyle, nullstrsetfn, zleunsetfn };
+static const struct gsu_scalar zle_state_gsu =
+{ get_zle_state, nullstrsetfn, zleunsetfn };
 
 static const struct gsu_integer bufferlines_gsu =
 { get_bufferlines, NULL, zleunsetfn };
@@ -134,6 +136,7 @@ static struct zleparam {
     { "WIDGET", PM_SCALAR | PM_READONLY, GSU(widget_gsu), NULL },
     { "WIDGETFUNC", PM_SCALAR | PM_READONLY, GSU(widgetfunc_gsu), NULL },
     { "WIDGETSTYLE", PM_SCALAR | PM_READONLY, GSU(widgetstyle_gsu), NULL },
+    { "ZLE_STATE", PM_SCALAR | PM_READONLY, GSU(zle_state_gsu), NULL },
     { NULL, 0, NULL, NULL }
 };
 
@@ -695,3 +698,22 @@ get_context(UNUSED(Param pm))
 	break;
     }
 }
+
+/**/
+static char *
+get_zle_state(UNUSED(Param pm))
+{
+    char *zle_state;
+
+    /*
+     * When additional substrings are added, they should be kept in
+     * alphabetical order, so the user can easily match against this
+     * parameter: if [[ $ZLE_STATE == *bar*foo*zonk* ]]; then ...; fi
+     */
+    zle_state = dupstring("");
+    if (!insmode) {
+	zle_state = dyncat(zle_state, "overwrite");
+    }
+
+    return zle_state;
+}
-- 
1.7.2.rc2

Re: PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck]

Frank Terbeck wrote:
> This is the $OVERWRITE idea converted to a string $ZLE_STATE, that may
> contain more than one attribute. Currently it only handles the status of
> the overwrite bit (!insmode).
> ---
>  Doc/Zsh/zle.yo       |    7 +++++++
>  Src/Zle/zle_params.c |   22 ++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)

So, about this.

I was thinking about adding support for signaling whether or not a
minibuffer is currently active. Turns out, that's not so easy. And even
if I had the information I'd still need some sort of hook-widget to be
called (like `zle-keymap-select()') to solve my particular problem.

Then I was thinking about adding a few more status strings, like
`isearch', `search' `execnacmedcmd' and `statusline' to be able to
figure out in shell code, if a minibuffer is active (the idea is to see
if isearch and a statusline are active, to conclude, that a minibuffer
is active). While that's easier, it still requires some widget to me
called automatically at the right times. And that's not the case.

So, I started to write a number of wrapper widgets that keep track of
zle's state entirely in shell code. That works surprisingly well. I
could even call "zle reset-prompt" from a TRAPINT(), which seems to
work. It just prints the following message to stderr:

      zle_thingy.c:649: line metafied

I'm ignoring that for now (2> /dev/null), since the widget does its
work.

What *is* the problem I'm trying to solve? Well, I'm trying to keep
track of what keyboard mode is currently active. I am keeping the
information in psvar[1], which I then use in my $PS1. The possible
values currently are:

       "i"  - insert mode
       "c"  - command mode
       "im" - insert mode, with a minibuffer being active
       "cm" - ditto, but for command mode
       "r"  - replace mode: insert mode with the overwrite bit set.

This works pretty well for all widgets I'm using, except for
`execute-named-command', because I cannot seem to create a wrapper
widget for that. I found this about the problem:

       http://www.zsh.org/mla/workers/2005/msg00384.html
       http://www.zsh.org/mla/workers/2005/msg00390.html

...so, I'm now settling to wait until 2012 about that. :-)

I'm pretty happy with my current setup anyway. It would be cool to have
a way to add a "V" mode to my prompt when `vared' is active. That could
probably be done with {pre,post}-vared hook widgets. I didn't look into
that yet, though.  (Actually, since I wrote this mail while being on a
train, I did look at this by now. This is not as trivial as I had hoped,
since zle cannot be run recursively. Oh well, I'm rarely using `vared'
anyway.)


Now, back to the patch at hand. Personally, I don't really need it
anymore. Since in vi-mode, I'm switching from one keyboard mode to
another directly, it's pretty hard for my code to get confused.

Still, when overwrite/non-overwrite mode is changed by toggling, like in
emacs mode, screwing up once, permanently confuses the state. And that's
as easy as "M-x .overwrite-mode RET".

So it might be worth committing this patch after all, since if
$ZLE_STATE contains "overwrite", you can be sure that's the state you're
in.

I'm not sure if the code is okay, though. I think using `dupstring()'
and `dyncat()' is correct, since the zle-widget is wrapped in
`pushheap()' and `popheap()'. That shouldn't leak, if I'm reading the
code correctly.  I am also not sure if that description of the new
variable in zshzle(1) is clear enough.

To cut a long story short: I'd like someone more competent to comment on
whether it's okay to commit this or not. :)

Regards, Frank

Re: PATCH: Add $ZLE_STATE in zle widgets

[Peter Stephenson]

On Fri, 06 Aug 2010 22:23:49 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> So, I started to write a number of wrapper widgets that keep track of
> zle's state entirely in shell code. That works surprisingly well. I
> could even call "zle reset-prompt" from a TRAPINT(), which seems to
> work. It just prints the following message to stderr:
> 
>       zle_thingy.c:649: line metafied
> 
> I'm ignoring that for now (2> /dev/null), since the widget does its
> work.

That's a bug that needs looking at.

> I'm pretty happy with my current setup anyway. It would be cool to
> have a way to add a "V" mode to my prompt when `vared' is active.
> That could probably be done with {pre,post}-vared hook widgets. I
> didn't look into that yet, though.  (Actually, since I wrote this
> mail while being on a train, I did look at this by now. This is not
> as trivial as I had hoped, since zle cannot be run recursively. Oh
> well, I'm rarely using `vared' anyway.)

Should be trivial to add this to ZLE_STATE internally.

> So it might be worth committing this patch after all, since if
> $ZLE_STATE contains "overwrite", you can be sure that's the state
> you're in.
>
> To cut a long story short: I'd like someone more competent to comment
> on whether it's okay to commit this or not. :)

It should be basically OK, though I'd be tempted to make it more
future-proof as below, which is rather picky, and make the documentation a
bit more explicit.

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.82
diff -p -u -r1.82 zle.yo
--- Doc/Zsh/zle.yo	22 Mar 2010 19:49:02 -0000	1.82
+++ Doc/Zsh/zle.yo	11 Aug 2010 11:58:56 -0000
@@ -854,6 +854,17 @@ executed; the second argument that follo
 defined.  This is the name of a builtin completion widget.  For widgets
 defined with tt(zle -N) this is set to the empty string.  Read-only.
 )
+vindex(ZLE_STATE)
+item(tt(ZLE_STATE) (scalar))(
+Contains a set of space-separated words that describe the current tt(zle)
+state.
+
+Currently, the only state shown is the insert mode as set by the
+tt(overwrite-mode) or tt(vi-replace) widgets.  The string contains
+`tt(insert)' if characters to be inserted on the command line move existing
+characters to the right, `tt(overwrite)' if characters to be inserted
+overwrite existing characters.
+)
 enditem()
 
 subsect(Special Widgets)
Index: Src/Zle/zle_params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_params.c,v
retrieving revision 1.34
diff -p -u -r1.34 zle_params.c
--- Src/Zle/zle_params.c	22 Mar 2010 16:26:00 -0000	1.34
+++ Src/Zle/zle_params.c	11 Aug 2010 11:58:56 -0000
@@ -76,6 +76,8 @@ static const struct gsu_scalar widgetfun
 { get_widgetfunc, nullstrsetfn, zleunsetfn };
 static const struct gsu_scalar widgetstyle_gsu =
 { get_widgetstyle, nullstrsetfn, zleunsetfn };
+static const struct gsu_scalar zle_state_gsu =
+{ get_zle_state, nullstrsetfn, zleunsetfn };
 
 static const struct gsu_integer bufferlines_gsu =
 { get_bufferlines, NULL, zleunsetfn };
@@ -134,6 +136,7 @@ static struct zleparam {
     { "WIDGET", PM_SCALAR | PM_READONLY, GSU(widget_gsu), NULL },
     { "WIDGETFUNC", PM_SCALAR | PM_READONLY, GSU(widgetfunc_gsu), NULL },
     { "WIDGETSTYLE", PM_SCALAR | PM_READONLY, GSU(widgetstyle_gsu), NULL },
+    { "ZLE_STATE", PM_SCALAR | PM_READONLY, GSU(zle_state_gsu), NULL },
     { NULL, 0, NULL, NULL }
 };
 
@@ -695,3 +698,60 @@ get_context(UNUSED(Param pm))
 	break;
     }
 }
+
+/**/
+static char *
+get_zle_state(UNUSED(Param pm))
+{
+    char *zle_state = NULL, *ptr = NULL;
+    int itp, istate, len = 0;
+
+    /*
+     * When additional substrings are added, they should be kept in
+     * alphabetical order, so the user can easily match against this
+     * parameter: if [[ $ZLE_STATE == *bar*foo*zonk* ]]; then ...; fi
+     */
+    for (itp = 0; itp < 2; itp++) {
+	char *str;
+	/*
+	 * Currently there is only one state: insert or overwrite.
+	 * This loop is to make it easy to add others.
+	 */
+	for (istate = 0; istate < 1; istate++) {
+	    int slen;
+	    switch (istate) {
+	    case 0:
+		if (insmode) {
+		    str = "insert";
+		} else {
+		    str = "overwrite";
+		}
+		break;
+
+	    default:
+		str = "";
+	    }
+	    slen = strlen(str);
+	    if (itp == 0) {
+		/* Accumulating length */
+		if (istate)
+		    len++;	/* for space */
+		len += slen;
+	    } else {
+		/* Accumulating string */
+		if (istate)
+		    *ptr++ = ' ';
+		memcpy(ptr, str, slen);
+		ptr += slen;
+	    }
+	}
+	if (itp == 0) {
+	    len++;		/* terminating NULL */
+	    ptr = zle_state = (char *)zhalloc(len);
+	} else {
+	    *ptr = '\0';
+	}
+    }
+
+    return zle_state;
+}

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: Add $ZLE_STATE in zle widgets

[Peter Stephenson]

On Wed, 11 Aug 2010 13:02:50 +0100
Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> > I'm pretty happy with my current setup anyway. It would be cool to
> > have a way to add a "V" mode to my prompt when `vared' is active.
> > That could probably be done with {pre,post}-vared hook widgets. I
> > didn't look into that yet, though.  (Actually, since I wrote this
> > mail while being on a train, I did look at this by now. This is not
> > as trivial as I had hoped, since zle cannot be run recursively. Oh
> > well, I'm rarely using `vared' anyway.)
> 
> Should be trivial to add this to ZLE_STATE internally.

Turns out you can already test [[ $CONTEXT = vared ]].

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck]

Peter Stephenson wrote:
> Peter Stephenson <Peter.Stephenson@csr.com> wrote:
>> > I'm pretty happy with my current setup anyway. It would be cool to
>> > have a way to add a "V" mode to my prompt when `vared' is active.
>> > That could probably be done with {pre,post}-vared hook widgets. I
>> > didn't look into that yet, though.  (Actually, since I wrote this
>> > mail while being on a train, I did look at this by now. This is not
>> > as trivial as I had hoped, since zle cannot be run recursively. Oh
>> > well, I'm rarely using `vared' anyway.)
>> 
>> Should be trivial to add this to ZLE_STATE internally.
>
> Turns out you can already test [[ $CONTEXT = vared ]].

Yes. But for my problem (signal that a vared is running in the shells
*main* prompt) that doesn't help, because there's no widget called
at the right time.

Regards, Frank

Re: PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck]

Peter Stephenson wrote:
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
[...]
>> To cut a long story short: I'd like someone more competent to comment
>> on whether it's okay to commit this or not. :)
>
> It should be basically OK, though I'd be tempted to make it more
> future-proof as below, which is rather picky, and make the documentation a
> bit more explicit.

This looks more thought-out than my version. Thanks. :)

Re: PATCH: Add $ZLE_STATE in zle widgets

[Peter Stephenson]

On Wed, 11 Aug 2010 14:54:42 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Peter Stephenson wrote:
> > Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> >> > I'm pretty happy with my current setup anyway. It would be cool
> >> > to have a way to add a "V" mode to my prompt when `vared' is
> >> > active. That could probably be done with {pre,post}-vared hook
> >> > widgets. I didn't look into that yet, though.  (Actually, since
> >> > I wrote this mail while being on a train, I did look at this by
> >> > now. This is not as trivial as I had hoped, since zle cannot be
> >> > run recursively. Oh well, I'm rarely using `vared' anyway.)
> >> 
> >> Should be trivial to add this to ZLE_STATE internally.
> >
> > Turns out you can already test [[ $CONTEXT = vared ]].
> 
> Yes. But for my problem (signal that a vared is running in the shells
> *main* prompt) that doesn't help, because there's no widget called
> at the right time.

The following seemed to work, am I missing what you're doing?

setopt promptsubst
PS1='$MYCONTEXT %# '
zle-line-init() {
  typeset -g MYCONTEXT=$CONTEXT
  zle reset-prompt
}
zle -N zle-line-init

Now "vared -p $PS1" shows up "vared", otherwise I get "start" (or, in
principle, "cont").

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck]

Peter Stephenson wrote:
> On Wed, 11 Aug 2010 14:54:42 +0200
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> Peter Stephenson wrote:
>> > Peter Stephenson <Peter.Stephenson@csr.com> wrote:
>> >> > I'm pretty happy with my current setup anyway. It would be cool
>> >> > to have a way to add a "V" mode to my prompt when `vared' is
>> >> > active. That could probably be done with {pre,post}-vared hook
>> >> > widgets. I didn't look into that yet, though.  (Actually, since
>> >> > I wrote this mail while being on a train, I did look at this by
>> >> > now. This is not as trivial as I had hoped, since zle cannot be
>> >> > run recursively. Oh well, I'm rarely using `vared' anyway.)
>> >> 
>> >> Should be trivial to add this to ZLE_STATE internally.
>> >
>> > Turns out you can already test [[ $CONTEXT = vared ]].
>> 
>> Yes. But for my problem (signal that a vared is running in the shells
>> *main* prompt) that doesn't help, because there's no widget called
>> at the right time.
>
> The following seemed to work, am I missing what you're doing?
>
> setopt promptsubst
> PS1='$MYCONTEXT %# '
> zle-line-init() {
>   typeset -g MYCONTEXT=$CONTEXT
>   zle reset-prompt
> }
> zle -N zle-line-init
>
> Now "vared -p $PS1" shows up "vared", otherwise I get "start" (or, in
> principle, "cont").

But that would put the information in vared's PS1 and not in the one of
the shell that called vared, wouldn't it? If I could do that, I'd know
if vared is active even without using its `-p' option.

I could live with doing this, though:
    vared() { builtin vared -p 'vared %% ' "$@" }

Regards, Frank

Re: PATCH: Add $ZLE_STATE in zle widgets

[Peter Stephenson]

On Wed, 11 Aug 2010 17:09:48 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> > setopt promptsubst
> > PS1='$MYCONTEXT %# '
> > zle-line-init() {
> >   typeset -g MYCONTEXT=$CONTEXT
> >   zle reset-prompt
> > }
> > zle -N zle-line-init
> >
> > Now "vared -p $PS1" shows up "vared", otherwise I get "start" (or,
> > in principle, "cont").
> 
> But that would put the information in vared's PS1 and not in the one
> of the shell that called vared, wouldn't it? If I could do that, I'd
> know if vared is active even without using its `-p' option.
> 
> I could live with doing this, though:
>     vared() { builtin vared -p 'vared %% ' "$@" }

vared doesn't have a prompt by default, so unless you're passing it one (in
which case you can always do somethign like what you're suggesting) I don't
see how there can be a problem.  Do you really mean you want a default
prompt for vared?  A wrapper for vared would probably be the best way of
doing that.

You're not talking about some use of recursive editing to read information
while the line editor is active, are you?  You can't do that with vared,
since zle isn't recursive, but you can do it with recursive-edit.  For the
same reason there's no question of having a valid shell prompt outside
vared while vared is running --- vared with its prompt (or lack of one) is
the only instance of zle at that point, and when zle is next started you
get a fresh prompt.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom