Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Some questions regarding prompt themes

* Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> [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


[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]

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

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_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.


> > * 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.


Thanks for your answer, Bart!

(-: Michael
".signature" [New] 1L, 22C [w]

Messages sorted by: Reverse Date, Date, Thread, Author