zle reset-prompt

zle reset-prompt

[Simon Friedberger]

Hello list subscribers!

I'm using zle reset-prompt as suggested on the wiki for displaying the
status of the vim bindings. It shows whether they are in insert or normal mode.

The problem with this is that zle reset-prompt resets the exit status of
the last command. I spoke to ft about this on irc and he was surprised
by the behavior so I thought I'd bring it up here. Is there something
like redraw-prompt that can be substituted? Is the behavior intentional?
etc. pp.

Best
Simon

Re: zle reset-prompt

[Peter Stephenson]

On Wed, 28 Jul 2010 22:15:36 +0200
Simon Friedberger <simon+zsh@a-oben.org> wrote:
> I'm using zle reset-prompt as suggested on the wiki for displaying the
> status of the vim bindings. It shows whether they are in insert or
> normal mode.
> 
> The problem with this is that zle reset-prompt resets the exit status
> of the last command.

That would certainly be a bug but it's not doing it here in 4.3.10-dev-2.
Does this happen if you run ESC x reset-prompt RETURN at the command
line?  If so, have you got something in your prompt that triggers this?

-- 
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: zle reset-prompt

[Simon Friedberger]

No, doesn't happen when I run it manually. I will try some more later
and get back to you.


On 10:04 Thu 29.07.10, Peter Stephenson wrote:
> On Wed, 28 Jul 2010 22:15:36 +0200
> Simon Friedberger <simon+zsh@a-oben.org> wrote:
> > I'm using zle reset-prompt as suggested on the wiki for displaying the
> > status of the vim bindings. It shows whether they are in insert or
> > normal mode.
> > 
> > The problem with this is that zle reset-prompt resets the exit status
> > of the last command.
> 
> That would certainly be a bug but it's not doing it here in 4.3.10-dev-2.
> Does this happen if you run ESC x reset-prompt RETURN at the command
> line?  If so, have you got something in your prompt that triggers this?
> 
> -- 
> 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: zle reset-prompt

[Simon Friedberger]

OK, so I tried a couple of possible calls with ESC x and the functions
in my prompt config.
It seems that zle-keymap-select might be the perpetrator.
Does that make any more sense?

On 15:55 Fri 30.07.10, Simon Friedberger wrote:
> No, doesn't happen when I run it manually. I will try some more later
> and get back to you.
> 
> 
> On 10:04 Thu 29.07.10, Peter Stephenson wrote:
> > On Wed, 28 Jul 2010 22:15:36 +0200
> > Simon Friedberger <simon+zsh@a-oben.org> wrote:
> > > I'm using zle reset-prompt as suggested on the wiki for displaying the
> > > status of the vim bindings. It shows whether they are in insert or
> > > normal mode.
> > > 
> > > The problem with this is that zle reset-prompt resets the exit status
> > > of the last command.
> > 
> > That would certainly be a bug but it's not doing it here in 4.3.10-dev-2.
> > Does this happen if you run ESC x reset-prompt RETURN at the command
> > line?  If so, have you got something in your prompt that triggers this?
> > 
> > -- 
> > 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: zle reset-prompt

[Peter Stephenson]

On Fri, 30 Jul 2010 16:08:28 +0200
Simon Friedberger <simon+zsh@a-oben.org> wrote:
> OK, so I tried a couple of possible calls with ESC x and the functions
> in my prompt config.
> It seems that zle-keymap-select might be the perpetrator.
> Does that make any more sense?

Not so far as I can see... I've run "bindkey -v", defined

zle-keymap-select() { print Status $?; } 
zle -N zle-keymap-select

the run "false", and when I hit ESC and i in turn I get "Status 1"
repeatedly.  If I've understood your problem, you're saying this would
give "Status 0" at some point.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: zle reset-prompt

[Frank Terbeck]

Peter Stephenson wrote:
> On Fri, 30 Jul 2010 16:08:28 +0200
> Simon Friedberger <simon+zsh@a-oben.org> wrote:
>> OK, so I tried a couple of possible calls with ESC x and the functions
>> in my prompt config.
>> It seems that zle-keymap-select might be the perpetrator.
>> Does that make any more sense?
>
> Not so far as I can see... I've run "bindkey -v", defined
>
> zle-keymap-select() { print Status $?; } 
> zle -N zle-keymap-select
>
> the run "false", and when I hit ESC and i in turn I get "Status 1"
> repeatedly.  If I've understood your problem, you're saying this would
> give "Status 0" at some point.

Yeah, it doesn't mess with `$?'.

But here's something I'm finding odd. Consider this setup from "zsh -f":

[snip]
bindkey -e
PS1='%? %% '
precmd() { true }
cs () {
    zle clear-screen
    zle reset-prompt
}
zle -N cs
bindkey '^l' cs
[snap]

Then this:
0 % false
1 % (hit ^l here)
[..screen is cleared..]
0 % echo $?
1
0 %

I thought `reset-prompt' alone was enough, but it's not. Also, this only
happens, when `clear-screen' and `reset-prompt are used in a single
widget. If called separately, this doesn't happen either.

Regards, Frank

Re: zle reset-prompt

[Peter Stephenson]

On Sat, 31 Jul 2010 20:34:56 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> I thought `reset-prompt' alone was enough, but it's not. Also, this only
> happens, when `clear-screen' and `reset-prompt are used in a single
> widget. If called separately, this doesn't happen either.

Aha, thanks, that's exactly what I need to know to pin down at least one
problem...  It's actually fairly obvious from your description.  We
maintain a global status which we save and restore within functions such
as zle widgets that aren't part of the main execution path, but we don't
explicitly restore that global status when redrawing the prompt, so if
we're already in a zle function and the local status has been changed we
use that.  So we need to maintain the global status specially for use in
this case.  However, we should still maintain the local status within the
function since it needs to obey normal syntax rules, so we have to save
and restore around the prompt redisplay, too.

This should fix that problem, anyway.  There's a pretty good chance this
is Simon's, too.

(See those things with slashes and stars?  Those are called
"comments"...  Yes, I'm still feeling a bit of completion code shell
shock.)

Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.123
diff -p -u -r1.123 zle_main.c
--- Src/Zle/zle_main.c	16 Dec 2009 18:39:06 -0000	1.123
+++ Src/Zle/zle_main.c	31 Jul 2010 19:22:03 -0000
@@ -84,6 +84,14 @@ int done;
 int mark;
 
 /*
+ * Status ($?) saved before function entry.  This is the
+ * status we need to use in prompts.
+ */
+
+/**/
+static int pre_zle_status;
+
+/*
  * Last character pressed.
  *
  * Depending how far we are with processing, the lastcharacter may
@@ -1129,6 +1137,12 @@ zleread(char **lp, char **rp, int flags,
 	free(pptbuf);
 	return shingetline();
     }
+    /*
+     * The current status is what we need if we are going
+     * to display a prompt.  We'll remember it here for
+     * use further in.
+     */
+    pre_zle_status = lastval;
 
     keytimeout = (time_t)getiparam("KEYTIMEOUT");
     if (!shout) {
@@ -1756,6 +1770,14 @@ reexpandprompt(void)
     static int reexpanding;
 
     if (!reexpanding++) {
+	/*
+	 * If we're displaying a status in the prompt, it
+	 * needs to be the toplevel one, not the one from
+	 * any status set within the local zle function.
+	 */
+	int local_lastval = lastval;
+	lastval = pre_zle_status;
+
 	free(lpromptbuf);
 	lpromptbuf = promptexpand(raw_lp ? *raw_lp : NULL, 1, NULL, NULL,
 				  &pmpt_attr);
@@ -1763,6 +1785,7 @@ reexpandprompt(void)
 	free(rpromptbuf);
 	rpromptbuf = promptexpand(raw_rp ? *raw_rp : NULL, 1, NULL, NULL,
 				  &rpmpt_attr);
+	lastval = local_lastval;
     }
     reexpanding--;
 }

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: zle reset-prompt

[Frank Terbeck]

Peter Stephenson wrote:
> On Sat, 31 Jul 2010 20:34:56 +0200
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
>> I thought `reset-prompt' alone was enough, but it's not. Also, this only
>> happens, when `clear-screen' and `reset-prompt are used in a single
>> widget. If called separately, this doesn't happen either.
>
> Aha, thanks, that's exactly what I need to know to pin down at least one
> problem...  It's actually fairly obvious from your description.  We
> maintain a global status which we save and restore within functions such
> as zle widgets that aren't part of the main execution path, but we don't
> explicitly restore that global status when redrawing the prompt, so if
> we're already in a zle function and the local status has been changed we
> use that.  So we need to maintain the global status specially for use in
> this case.  However, we should still maintain the local status within the
> function since it needs to obey normal syntax rules, so we have to save
> and restore around the prompt redisplay, too.
>
> This should fix that problem, anyway.  There's a pretty good chance this
> is Simon's, too.

Yes, this fixes it for me. Thanks.

Regards, Frank