Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Some questions regarding prompt themes
- X-seq: zsh-workers 20264
- From: Michael Prokop <news@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Some questions regarding prompt themes
- Date: Mon, 16 Aug 2004 13:00:55 +0200
- In-reply-to: <Pine.LNX.4.61.0408160052080.21654@xxxxxxxxxxxxxxxxxx>
- Mail-followup-to: zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <2004-08-16T08-32-23@xxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0408160052080.21654@xxxxxxxxxxxxxxxxxx>
- Reply-to: Michael Prokop <zsh@xxxxxxxxxxxxxxxxx>
* 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
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 precmdstatement?
> 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]
Messages sorted by:
Reverse Date,
Date,
Thread,
Author