promptsubst and empty variables

promptsubst and empty variables

[Frank Terbeck]

I am seeing some weirdness using prompt_subst and empty variables in
RPS1 (from zsh -f):

[snip]
setopt promptsubst
RPROMPT='${foo}'
PROMPT='${bar}'
bar='%~%# '
[snap]

This results in the following cursor position:

~%_
  ^- At the underscore, that's where the cursor is. Note, the missing
     trailing space.

I've tried this with quite a few versions of zsh and I'm seeing this
with almost very version I tried:

    + it's not in 3.0, at least not in the versions I tried (not all)
    + it is in every version starting from 3.1.6 except:
        - 4.3.1 and 4.3.2
        - it's back in 4.3.3 and remains to be in the CVS HEAD
          version.


As soon as you but something into $foo in the above snippet (a simple
foo=. is enough), you get the trailing space.

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: promptsubst and empty variables

[Bart Schaefer]

On Sep 14, 11:24am, Frank Terbeck wrote:
}
} I am seeing some weirdness using prompt_subst and empty variables in
} RPS1 (from zsh -f):
} 
} [snip]
} setopt promptsubst
} RPROMPT='${foo}'

I get the misplaced cursor right here; there doesn't need to be a value
assigned to PROMPT with or without a substitution in it.

} This results in the following cursor position:
} 
} ~%_
}   ^- At the underscore, that's where the cursor is. Note, the missing
}      trailing space.
} 
}     + it is in every version starting from 3.1.6 except:
}         - 4.3.1 and 4.3.2
}         - it's back in 4.3.3 and remains to be in the CVS HEAD
}           version.

I can't follow how any of the 4.3.0->4.3.1 changes could have affected
this, but anyway ...

The problem is that singsub() called from promptexpand() is returning
nulstring, which is the Nularg token followed by a NUL byte.

This is incorrectly being interpreted by promptexpand() as a so-called
"glitch" space passed down from the caller, and is therefore counted
as one space in the width of the prompt.

Unfortunately having learned this much, I have very little idea how to
proceed with fixing it.  One possibility might be to do a first pass
over the string counting and removing all "glitches" before making the
call to singsub(), so that Nularg introduced by substitution could be
ignored in a second pass.  Another might be to introduce a real token
for the "glitch" space rather than overloading Nularg, but that may
have pretty wide-ranging ramifications.

Wayne, this is mostly your baby.  What to do?

Re: promptsubst and empty variables

[Peter Stephenson]

On Sun, 14 Sep 2008 09:43:22 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 14, 11:24am, Frank Terbeck wrote:
> }
> } I am seeing some weirdness using prompt_subst and empty variables in
> } RPS1 (from zsh -f):
> } 
> } [snip]
> } setopt promptsubst
> } RPROMPT='${foo}'
> 
> I get the misplaced cursor right here; there doesn't need to be a value
> assigned to PROMPT with or without a substitution in it.
> 
> The problem is that singsub() called from promptexpand() is returning
> nulstring, which is the Nularg token followed by a NUL byte.

I hope, actually, it's dupstring(nulstring), or substitution is a bit
broken.

I don't think we need the Nularg in this case since although the string is
metafied we're not doing anything special with tokens.  However, I've never
understood what this was for in the first place, so I may have missed
something.  If I have, however, we're not going to find out without trying
it.

Index: Src/prompt.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v
retrieving revision 1.52
diff -u -r1.52 prompt.c
--- Src/prompt.c	24 Jun 2008 08:44:16 -0000	1.52
+++ Src/prompt.c	15 Sep 2008 14:27:44 -0000
@@ -169,6 +169,12 @@
 	s = dupstring(s);
 	if (!parsestr(s))
 	    singsub(&s);
+	/*
+	 * We don't need the special Nularg hack here and we're
+	 * going to be using Nularg for other things.
+	 */
+	if (*s == Nularg && s[1] == '\0')
+	    *s = '\0';
 
 	/* Ignore errors and status change in prompt substitution */
 	errflag = olderr;


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

Re: promptsubst and empty variables

[Frank Terbeck]

Peter Stephenson <pws@csr.com>:
[...]
> I hope, actually, it's dupstring(nulstring), or substitution is a bit
> broken.
> 
> I don't think we need the Nularg in this case since although the string is
> metafied we're not doing anything special with tokens.  However, I've never
> understood what this was for in the first place, so I may have missed
> something.  If I have, however, we're not going to find out without trying
> it.
[...]
> +	/*
> +	 * We don't need the special Nularg hack here and we're
> +	 * going to be using Nularg for other things.
> +	 */
> +	if (*s == Nularg && s[1] == '\0')
> +	    *s = '\0';

I just gave this a try.
And it fixes the problem for me. For my test case as well as my real
prompt - which wasn't struck by the problem, but this change does not
break anything, AFAICS.

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