Some questions regarding prompt themes

Some questions regarding prompt themes

[Michael Prokop]

Hello,

I've tested the below documented behaviour with zsh versions 4.2.0
and 4.2.1 (CVS-sources). Some time ago I wrote my own prompt-themes
and noticed a (at least for me) strange and maybe unwanted
behaviour:

$ zsh -f
$ echo $PROMPT $PS1 $PS2 $PS3 $PS4
%m%#  %m%#  %_>  ?#  +%N:%i>
$ autoload promptinit && promptinit
$ prompt -p           # Preview given themes (defaults to all)
[...]
mika@tweety ~ %

Now I've a PROMPT-variable different from the above ("%m%# ").

Bart Schaefer wrote:

,---- [ Quoting http://www.zsh.org/mla/workers/2003/msg00434.html ]
| } One problem I noticed the other day is if one prompt sets PS3, PS4, or
| } RPS1, then those vars won't get reset when changing prompts, even when
| } setting the prompt to "off".
|
| It's a general shortcoming that themes only change the parts of the prompt
| that they're interested in; "off" is just another theme with a silly name.
|
| To really have "prompt off" mean what it seems to mean, the theme system
| would have to save and restore the original values of all the variables.
`----

My questions:

* In the prompt-theme "walters" exists a "export PROMPT=...":

$ grep -l export /usr/share/zsh/4.2.0/functions/Prompts/prompt*
  /usr/share/zsh/4.2.0/functions/Prompts/prompt_walters_setup

  Is using 'export PROMPT' in prompt-themes reasonable?

* Is it possible to "break out" of a precmd­statement?
  Some themes are using the precmd-option:

$ pwd && grep -l precmd *prompt*  | wc -l
  /usr/share/zsh/4.2.0/functions/Prompts
  13
$ grep 'precmd.*prompt_' *prompt* | wc -l
  8

  e.g. prompt_adam1_setup sets the prompt via the precmd statement.
  AFAICS this results in problems when running stuff like
    export PS1='test'
  manually ­ which IMHO does not work as it should.

* Would it be possible that 'prompt -p' does *not* export any
  prompt-variables so the prompt doesn't get modified by just
  running a preview of one/some/all themes?

* Does there exist a way to reset all prompt-values? Something like
  'prompt reset' would be very nice IMHO.

* What's the "right" way to set variables in a prompt-theme to avoid
  problems with other themes?  Would it make sense to "unset PS1
  PS2..." at the beginning of a prompt-theme to avoid any
  side-effects from other themes?

thanks for any feedback && regards,
(-: Michael
-- 
A german webpage for zsh / eine deutsche Webpage zur zsh:
http://www.michael-prokop.at/computer/tools_zsh.html
Die Zsh-Liebhaber-Seite:
http://www.michael-prokop.at/computer/tools_zsh_liebhaber.html

Re: Some questions regarding prompt themes

[Bart Schaefer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3237 bytes --]

On Mon, 16 Aug 2004, Michael Prokop wrote:

>   Is using 'export PROMPT' in prompt-themes reasonable?

Evidently Colin Walters thought so, or whoever stole from him.  It's not 
ideal.  The prompinit wrapper saves and restores PS1 et al., but not 
PROMPT nor RPROMPT, when running preview.  I would have expected the 
restoration of PS1 at exit from the function to restore PROMPT as a 
side-effect of their linkage, and it seems to do so when I try it, so I 
don't know offhand what's happening to you.

The "mike@tweety ~ % " prompt doesn't look like it came from any of the
zsh prompt themes I'm familiar with.  Certainly not walters, which would 
be "mike@tweety> ", nor zefram which is always the last theme previewed.

> * Is it possible to "break out" of a precmd­statement?

I don't know what you're asking.

>   Some themes are using the precmd-option

Yes, sadly, several of the themes assume you don't have anything better to 
do with your precmd than fiddle with the prompt.  You'll note the "bart"
theme goes to some lengths to avoid wrecking any existing precmd function.

>   e.g. prompt_adam1_setup sets the prompt via the precmd statement.
>   AFAICS this results in problems when running stuff like
>     export PS1='test'
>   manually ­ which IMHO does not work as it should.

Hey, you either get a themed prompt or you don't.  Why would you expect 
that assigning to PS1 was enough to disable an entire prompt theme?

(Just wait until we get ksh-style "discipline functions," though.)

> * Would it be possible that 'prompt -p' does *not* export any
>   prompt-variables so the prompt doesn't get modified by just
>   running a preview of one/some/all themes?

"prompt -p" doesn't do anything except make a stab at saving state and 
then blindly run each of the theme setup and preview functions in turn.  
It's up to the theme writers to make the themes play nice, and some of 
them don't, er, didn't.

Probably preview (and help) could be executed in a subshell nowadays, to 
avoid all this hassle.  When the theme system was first written, some 
things like the job table didn't behave well in subshells, but that's 
pretty much been fixed up in 4.2.x.

> * Does there exist a way to reset all prompt-values? Something like
>   'prompt reset' would be very nice IMHO.

Nothing's changed since I wrote the previous response that you excerpted:
| To really have "prompt off" mean what it seems to mean, the theme system
| would have to save and restore the original values of all the variables.

The theme system does not save the original values of all the variables.

> * What's the "right" way to set variables in a prompt-theme to avoid
>   problems with other themes?  Would it make sense to "unset PS1
>   PS2..." at the beginning of a prompt-theme to avoid any
>   side-effects from other themes?

It's a philosophical thing.  E.g. "prompt bart" doesn't mess with RPS1 
except to color it; so whatever the previous value was will still be 
there, which is fine because my prompt doesn't need it for anything.  My 
theme also keeps whatever was in PS1 to begin with, it just prefixes it 
with more stuff.

But none of the prompt themes know about RPS2, because it didn't exist
when the theme system was written.

Re: Some questions regarding prompt themes

[Michael Prokop]

* Bart Schaefer <schaefer@brasslantern.com> [20040816 10:47]:
> On Mon, 16 Aug 2004, Michael Prokop wrote:

> >   Is using 'export PROMPT' in prompt-themes reasonable?

> Evidently Colin Walters thought so, or whoever stole from him.  It's not 
> ideal.  The prompinit wrapper saves and restores PS1 et al., but not 
> PROMPT nor RPROMPT, when running preview.  I would have expected the 
> restoration of PS1 at exit from the function to restore PROMPT as a 
> side-effect of their linkage, and it seems to do so when I try it, so I 
> don't know offhand what's happening to you.

It seems to be related to some side-effects regarding precmd/preexec
and/or handling of variables:

[mika@tweety(500): ~]$ prompt adam1   # this line shows my own theme
mika@tweety ~ % prompt walters        # this line shows adam1 theme
mika@tweety ~ %                       # and now I expected to see
                                      # walters theme but still see
                                      # adam1

But:

[mika@tweety(500): ~]$ prompt bart    # as you can see in the next line...
[mika@tweety(501): ~]$ zsh -f         # ... I don't "see" your theme
tweety% autoload promptinit && promptinit
tweety% prompt bart                   # ok, let's use your theme now
tweety [prompt bart] ~                [cut of long line by me] # works
tweety% prompt walters                # now try to switch to walters theme
mika@tweety> prompt bart              # going back to your theme works again:
tweety [prompt bart] ~                [cut of long line by me]
mika@tweety>

Except for the first line in the second example (calling 'prompt
bart' from my theme) everything worked as I expected it to. As you
mentioned in your mail your theme does some checking. Thanks for
this hint, I'll take a closer look at your theme.

Of course calling 'prompt off' and 'prompt bart' works for the first
example too.

Why I was confused:

[mika@tweety(502): ~]$ zsh --help | grep -- '-f '
  -f    equivalent to --no-rcs
[mika@tweety(503): ~]$ zsh -f
tweety%                               # now I'm terminating the "no-rcs-shell"
[mika@tweety(504): ~]$ prompt adam1
mika@tweety ~ % zsh -f
tweety%

Ok, this works as I expected it to. But:

[mika@tweety(500): ~]$ prompt walters # you see my prompt, now let's call walters
[mika@tweety(501): ~]$ zsh -f         # ok, does not work
[mika@tweety(1): ~]$

And now I don't get the 'tweety% '-prompt I expected to see.

> The "mike@tweety ~ % " prompt doesn't look like it came from any of the
> zsh prompt themes I'm familiar with.  Certainly not walters, which would 
> be "mike@tweety> ", nor zefram which is always the last theme previewed.

It took me some time to figure out what has happend here in detail.
AFAICS it's the first theme using precmd:

[mika@tweety(501): ~]$ prompt adam1
mika@tweety ~ %

> > * Is it possible to "break out" of a precmd­statement?

> I don't know what you're asking.

Sorry, I'll try to explain it with an example:

I'm setting my prompt via precmd:

,---- [ listing of ~/.zsh/func/prompt_smart_setup ]
| setpromptsmart () {
|   [...]
|   if [[ "$TERM" != "dumb" ]]; then
|     PROMPT="$SCREENTITLE$TITLEBAR$C_EXIT$EXITCODE$C_BRACKETS$BRACKET_L$C_USER%n$C_AT@$C_HOST%m$C_HISTORY(%!): $C_CWD%~$C_BRACKETS$BRACKET_R$C_RESET$ "
|   [...]
| }
|
| prompt_smart_setup () {
|   precmd () { setopt promptsubst; prompt_smart_precmd; setpromptsmart }
| }
`----

[mika@tweety(502): ~]$ echo $PROMPT
%{%}%{%}%(?..%?%1v )%{%}[%{%}%n%{%}@%{%}%m%{%}(%!): %{%}%~%{%}]%{%}$
[mika@tweety(503): ~]$

(sorry, of course the "strange" $PROMPT is not really the one I'm
seeing here. Is it possible to echo it without getting colors
interpreted by the terminal?)

[mika@tweety(503): ~]$ export PROMPT=blub
[mika@tweety(504): ~]$
[mika@tweety(505): ~]$ export PS1=blub
[mika@tweety(506): ~]$

- so now it's not possible to export prompt-variables again.

This is what I meant. If I unterstood you right the best working
solution ist to run:

[some_prompt_theme_in_here] $ prompt off
% export P1=...

> >   Some themes are using the precmd-option

> Yes, sadly, several of the themes assume you don't have anything better to 
> do with your precmd than fiddle with the prompt.  You'll note the "bart"
> theme goes to some lengths to avoid wrecking any existing precmd function.

Thanks for pointing out.

What I do really like at the precmd/preexec is checking for
exit-status and setting titles of screen and xterm.

> >   e.g. prompt_adam1_setup sets the prompt via the precmd statement.
> >   AFAICS this results in problems when running stuff like
> >     export PS1='test'
> >   manually ­ which IMHO does not work as it should.

> Hey, you either get a themed prompt or you don't.  Why would you expect 
> that assigning to PS1 was enough to disable an entire prompt theme?

Of course you are right. Thanks for the hint.

> (Just wait until we get ksh-style "discipline functions," though.)

Sounds nice :)

> > * Would it be possible that 'prompt -p' does *not* export any
> >   prompt-variables so the prompt doesn't get modified by just
> >   running a preview of one/some/all themes?

> "prompt -p" doesn't do anything except make a stab at saving state and 
> then blindly run each of the theme setup and preview functions in turn.  
> It's up to the theme writers to make the themes play nice, and some of 
> them don't, er, didn't.

This is exactly what I thought.

> Probably preview (and help) could be executed in a subshell nowadays, to 
> avoid all this hassle.  When the theme system was first written, some 
> things like the job table didn't behave well in subshells, but that's 
> pretty much been fixed up in 4.2.x.

This would be nice. At least for me it was a little bit confusing to
get an altered prompt after using the preview-function ;)

> > * Does there exist a way to reset all prompt-values? Something like
> >   'prompt reset' would be very nice IMHO.

> Nothing's changed since I wrote the previous response that you excerpted:
> | To really have "prompt off" mean what it seems to mean, the theme system
> | would have to save and restore the original values of all the variables.

> The theme system does not save the original values of all the variables.

Ok.

> > * What's the "right" way to set variables in a prompt-theme to avoid
> >   problems with other themes?  Would it make sense to "unset PS1
> >   PS2..." at the beginning of a prompt-theme to avoid any
> >   side-effects from other themes?

> It's a philosophical thing.  E.g. "prompt bart" doesn't mess with RPS1 
> except to color it; so whatever the previous value was will still be 
> there, which is fine because my prompt doesn't need it for anything.  My 
> theme also keeps whatever was in PS1 to begin with, it just prefixes it 
> with more stuff.

Thanks for this hint. I'll try to check this out.

> But none of the prompt themes know about RPS2, because it didn't exist
> when the theme system was written.

Ok.

Thanks for your answer, Bart!

regards,
(-: Michael
-- 
www.michael-prokop.at
~
~
".signature" [New] 1L, 22C [w]