Re: 4.3.17 unset RPS1 vs RPROMPT

[Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>]

On 2012-06-29 at 19:52 +0100, Peter Stephenson wrote:
> I'm still not really following what you're trying to do, but my guess is
> you're not actually trying to unset the variable at all, you're trying
> to set it to an empty string.  They may sound similar, and they often
> have the same effect, but they are different things.  If the variable is
> unset, it is indeed uncoupled from anything else that's going on, which
> is kind of what unset means.  So unsetting an unset variable does indeed
> have no effect.

I'd decided it was a bug because that's what unset means, but setting it
again rebinds it to have the same meaning as before, so it can't be
meaningfully unset.  You can't rebind the variable name to a different
internal structure, so at this point the semantics become somewhat
messed up.

I think that there's a bug here, but deciding what the correct behaviour
should be is non-trivial and certainly not worth blocking 5.0.0 for.

Fundamentally, in zsh at present, it seems that magic variables can not
have their magic purged from them as the names can never truly be
unbound, just temporarily made unavailable, yet the same content can be
available under other names.  For library-level robustness against
someone having set a prompt variable (PROMPT3/PS3 for instance) but
unbound one of the names, getting back consistent state seems to require
setting both names and only caring about the value of which one is set
second, so that both names remain available thereafter.

If the name could be rebound to another variable and no longer be magic,
the current approach would be sane, but it seems that perhaps the
correct behaviour should be to ensure that whatever the state of one
name, the other name should be in the same state: set, unset, empty,
with-content, whatever.

Perhaps I've become contaminated with the Pythonic approach of being
distinct about the binding of a name to a variable versus the changing
of the value of a variable.

-Phil