Re: When RPROMPT != RPS1

[Bart Schaefer <schaefer@brasslantern.com>]

On Jun 20,  1:22pm, Jim wrote:
}
} > After switching from walters to say adam, I unset "RPS1",
} > but the right prompt remained.  I then typed
} > "unset RPROMPT" and the right prompt was no longer there.
} 
} I should have checked earlier. I'm seeing the same thing with
} RPS2 and RPROMPT2.

What's going on here is that RPROMPT, RPS1, RROMPT2, and RPS2 always
start out as unset, so assigning to one of each pair does not cause
the second one to magically become set.  Then if you unset any one
that is already unset, nothing happens (including not unsetting the
paired one).

The assumption is that under normal circumstances the user will not
be arbitrarily/randomly switching which name he prefers to use.  The
prompt themes mess with that because they combine code from several
different users.

The reason they start out as unset is explained here:
http://www.zsh.org/mla/workers/2014/msg00128.html

The argument/complaint was that if those parameters have no meaning
in an emulation mode, then they should not be set at all, thereby
allowing scripts in the emulation to use those names any way they
want without triggering the pairing behavior.

I don't have a good suggestion for how to satisfy both constraints.
Anyone?  The parameter initialization code has been broken up into
a few more sections already, maybe there's a way to rearrange these
as well.

} In addition the promptinit function doesn't set RPS2:
} 
}     local +h PS1=$PS1 PS2=$PS2 PS3=$PS3 PS4=$PS4 RPS1=$RPS1

Yeah, I'm not sure why it's done that way; the prompt_bart_setup doc
even says:
    If a fifth color is specified and there is no RPS2, PS2 (PROMPT2)
    is colored and moved to RPS2.  Changes to RPS1/RPS2 are currently
    not reverted when the theme is switched off.

Obviously, though, that "local" command was written before the change
from workers/32337 was applied.