* Re: Prompt themes
[not found] ` <20030124211240.GD6160@io.com>
@ 2003-02-03 11:24 ` Clemens Fischer
0 siblings, 0 replies; 6+ messages in thread
From: Clemens Fischer @ 2003-02-03 11:24 UTC (permalink / raw)
To: zsh-workers; +Cc: zsh-users
John Buttery <john@io.com>:
> [...] I have a habit of making (or trying to) a
> complete configuration file for a program as soon as I install it (as
> in, before I fully understand it).
> Disadvantage: Sometimes things are broken for a while when I first
> install them. I find this provides suitable motivation. :)
> Advantage: Tickled pink feeling of accomplishment as everything comes
> together at once at the end.
admit it: you're never really done :)
clemens
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: prompt themes
2003-06-04 13:01 ` Dirus
2003-06-04 15:01 ` Oliver Kiddle
@ 2003-06-04 17:21 ` Bart Schaefer
1 sibling, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2003-06-04 17:21 UTC (permalink / raw)
To: zsh-workers
On Jun 4, 6:01am, Dirus wrote:
}
} ><snip> It should
} >probably also do a preview even if there isn't a prompt_X_preview function
} >- there isn't for most.
}
} The problem here is we don't know how many parameters the themes
} take.
If the theme doesn't work with zero parameters, it's broken. If there is
no preview function, don't try to guess at parameters; preview whatever
the defaults are.
[Regarding help]
}
} I see your point. Using cat is pretty straight forward, and I am happy
} to leave it alone. :) The only advantage to using $REPLY here would be
} that if you intended on using the help string without directly echoing
} it to the screen.
If you want a description that isn't meant to be displayed as-is, add
another one; don't overload use of the help function.
See prompt_bart_help in prompt_bart_setup for a good reason why not.
} >There's probably quite a few aspects of the prompt theming that could
} >be improved. Making colour schemes independent of specific fonts would
} >be one example. <snip>
}
} Maybe you mean making color schemes independent of specific themes?
No, he means exactly what he said. There are some fonts that have half-
tone special characters, and some of the themes rely on those fonts to
get a "fade" effect from one color to another.
} 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.
} There do seem to be some problems with the distributed themes descriptions
} too, for example adam1 (correct me if I'm wrong) says it requires an 8 bit
} font when it doesn't.
The usual case of the doc not keeping pace with other changes. It did
require an 8bit font at one time.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: prompt themes
2003-06-04 13:01 ` Dirus
@ 2003-06-04 15:01 ` Oliver Kiddle
2003-06-04 17:21 ` Bart Schaefer
1 sibling, 0 replies; 6+ messages in thread
From: Oliver Kiddle @ 2003-06-04 15:01 UTC (permalink / raw)
To: Dirus; +Cc: zsh-workers
Dirus wrote:
> It's not really much to complain about, it just seems counter
> intuitive... any theme with a prompt_X_preview function, will look
> something like this:
> preview prompt
> print blank line
> preview prompt
> print blank line
> preview prompt
I see, that is a bit crap. Shouldn't be hard to make the preview function
output the blank lines instead.
> ><snip> It should
> >probably also do a preview even if there isn't a prompt_X_preview function
> >- there isn't for most.
> The problem here is we don't know how many parameters the themes
> take. Some might take 2 colors, others 4... and even some such as the
For this fallback preview, it should work to just try the themes with no
parameters at all. If any don't assume default values for their
parameters then they should.
> Maybe you mean making color schemes independent of specific themes?
Yes, sorry that's what I meant. What I have in mind is that the colour
schemes would also handle other things like LS_COLOURS.
> 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". A good example here is the walters theme and
> its RPS1 setting, it will follow you around when you change prompts.
That is a bit of a problem. The theme system should perhaps save values
so that they can be restored.
> There do seem to be some problems with the distributed themes descriptions
> too, for example adam1 (correct me if I'm wrong) says it requires an 8 bit
> font when it doesn't. As for requiring an old school terminal type (8 bit)
Yes, comment in adam1 seems to be wrong, especially the bit about adam1
being overkill showing that it must have been a copy and paste from
adam2.
> font, some fancy things such as the connecting lines just can't be done
> with a 7 bit font. Perhaps it would be best to set up the prompt themes so
> they do not use 8 bit font characters unless specified. On the other hand
> we could try to parse the $TERM to make an educated guess, but it probably
> couldn't be done properly.
I don't think $TERM will give you much clue about the font. The locale
character encoding might and the new \u would in theory allow the correct
characters to be retrieved but I suspect that anyone using `vga' or
`nexus' fonts is actually using an ISO-8859-1 locale.
Oliver
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: prompt themes
2003-06-04 9:41 ` Oliver Kiddle
@ 2003-06-04 13:01 ` Dirus
2003-06-04 15:01 ` Oliver Kiddle
2003-06-04 17:21 ` Bart Schaefer
0 siblings, 2 replies; 6+ messages in thread
From: Dirus @ 2003-06-04 13:01 UTC (permalink / raw)
To: zsh-workers; +Cc: Oliver Kiddle
At 02:41 AM 6/4/2003, Oliver wrote:
>Dirus wrote:
> > prompt_X_preview doesn't print the first or last blank line. This means
> > the person writing the prompt theme would have to print the blank lines
> > between sample settings without printing the first or last. Whoever is
>
>I'm not quite sure which blank lines you're talking about.
It's not really much to complain about, it just seems counter
intuitive... any theme with a prompt_X_preview function, will look
something like this:
preview prompt
print blank line
preview prompt
print blank line
preview prompt
and promptinit's prompt function will add the first and last blank line.
><snip> It should
>probably also do a preview even if there isn't a prompt_X_preview function
>- there isn't for most.
The problem here is we don't know how many parameters the themes
take. Some might take 2 colors, others 4... and even some such as the
adam2 prompt theme take an '8bit' parameter. Perhaps it would be best to
simply add a list of previews those that could use one, it wouldn't take
more than a couple minutes to find a couple settings for each that look decent.
> > Ideally prompt_X_preview would look like this:
> > prompt_X_preview() {
> > reply=' singleparameter "param1 param2" "param1 param2" '
> > }
>
>Or, since it is an array,
> reply=( singleparameter "param1 param2" "param1 param2" )
Oh hmm, yes that is better, and it would save a '(z)'.
> > Also prompt_X_help could also be changed to set $reply for consistency
> sake.
>
>I'm less convinced by that idea. There's not really any code that can
>be factored out and it wouldn't make the functions any simpler.
I see your point. Using cat is pretty straight forward, and I am happy to
leave it alone. :) The only advantage to using $REPLY here would be that
if you intended on using the help string without directly echoing it to the
screen. Perhaps for some reason you wanted to format it for a menu based
prompt selector where you only have a set space to squish the help text
into, and even then you could probably work around it.
> > Anyone interested in seeing this? Is it best to just send the diffs to
> the
> > mailing list? There would be a lot of them, one for each prompt theme and
> > one for promptinit.
>
>Just send a diff.
Ok. Will do.
>There's probably quite a few aspects of the prompt theming that could
>be improved. Making colour schemes independent of specific fonts would
>be one example. <snip>
Maybe you mean making color schemes independent of specific themes?
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". A good example here is the walters theme and
its RPS1 setting, it will follow you around when you change prompts.
><snip> Perhaps sorting through the distributed themes too: it
>isn't ideal that many don't work right unless your use some peculiar
>font and terminal emulator.
There do seem to be some problems with the distributed themes descriptions
too, for example adam1 (correct me if I'm wrong) says it requires an 8 bit
font when it doesn't. As for requiring an old school terminal type (8 bit)
font, some fancy things such as the connecting lines just can't be done
with a 7 bit font. Perhaps it would be best to set up the prompt themes so
they do not use 8 bit font characters unless specified. On the other hand
we could try to parse the $TERM to make an educated guess, but it probably
couldn't be done properly.
-Dirus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: prompt themes
2003-06-03 16:55 prompt themes Dirus
@ 2003-06-04 9:41 ` Oliver Kiddle
2003-06-04 13:01 ` Dirus
0 siblings, 1 reply; 6+ messages in thread
From: Oliver Kiddle @ 2003-06-04 9:41 UTC (permalink / raw)
To: Dirus; +Cc: zsh-workers
Dirus wrote:
> I had been playing around with prompt themes a bit and I noticed a couple
> of things.
>
> prompt_X_preview doesn't print the first or last blank line. This means
> the person writing the prompt theme would have to print the blank lines
> between sample settings without printing the first or last. Whoever is
I'm not quite sure which blank lines you're talking about.
> writing the function also has to check "if (( ! $#* ));" to see if the user
> passed in any parameters himself. Each prompt_X_preview function will have
> a lot of duplicate code.
I agree. It would probably be sensible if the theme system automatically
checked that and ran prompt_preview_theme with the parameters. It should
probably also do a preview even if there isn't a prompt_X_preview function
- there isn't for most.
> In the interest of consolidating all of the code and logic to one place and
> also to make it easier for a person to set up a preview for their theme,
> I'd like to create a patch for the prompt theming (and it's themes) that
> that causes prompt_X_preview to return a list of settings in $reply (or
> $REPLY). (Is the lowercase preferred for an array of values?)
Yes, $reply for array values.
> Ideally prompt_X_preview would look like this:
> prompt_X_preview() {
> reply=' singleparameter "param1 param2" "param1 param2" '
> }
Or, since it is an array,
reply=( singleparameter "param1 param2" "param1 param2" )
> Also prompt_X_help could also be changed to set $reply for consistency sake.
I'm less convinced by that idea. There's not really any code that can
be factored out and it wouldn't make the functions any simpler.
> Anyone interested in seeing this? Is it best to just send the diffs to the
> mailing list? There would be a lot of them, one for each prompt theme and
> one for promptinit.
Just send a diff.
There's probably quite a few aspects of the prompt theming that could
be improved. Making colour schemes independent of specific fonts would
be one example. Perhaps sorting through the distributed themes too: it
isn't ideal that many don't work right unless your use some peculiar
font and terminal emulator.
Oliver
PS. If anyone wants it, I have an MH prompt theme which sticks the
current folder and message number in the prompt.
^ permalink raw reply [flat|nested] 6+ messages in thread
* prompt themes
@ 2003-06-03 16:55 Dirus
2003-06-04 9:41 ` Oliver Kiddle
0 siblings, 1 reply; 6+ messages in thread
From: Dirus @ 2003-06-03 16:55 UTC (permalink / raw)
To: zsh-workers
I had been playing around with prompt themes a bit and I noticed a couple
of things.
prompt_X_preview doesn't print the first or last blank line. This means
the person writing the prompt theme would have to print the blank lines
between sample settings without printing the first or last. Whoever is
writing the function also has to check "if (( ! $#* ));" to see if the user
passed in any parameters himself. Each prompt_X_preview function will have
a lot of duplicate code.
In the interest of consolidating all of the code and logic to one place and
also to make it easier for a person to set up a preview for their theme,
I'd like to create a patch for the prompt theming (and it's themes) that
that causes prompt_X_preview to return a list of settings in $reply (or
$REPLY). (Is the lowercase preferred for an array of values?)
Ideally prompt_X_preview would look like this:
prompt_X_preview() {
reply=' singleparameter "param1 param2" "param1 param2" '
}
Also prompt_X_help could also be changed to set $reply for consistency sake.
Anyone interested in seeing this? Is it best to just send the diffs to the
mailing list? There would be a lot of them, one for each prompt theme and
one for promptinit.
-Dirus
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-06-04 17:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <6134254DE87BD411908B00A0C99B044F03A0B5FA@mowd019a.mow.siemens.ru>
[not found] ` <1030123180207.ZM12877@candle.brasslantern.com>
[not found] ` <20030124211240.GD6160@io.com>
2003-02-03 11:24 ` Prompt themes Clemens Fischer
2003-06-03 16:55 prompt themes Dirus
2003-06-04 9:41 ` Oliver Kiddle
2003-06-04 13:01 ` Dirus
2003-06-04 15:01 ` Oliver Kiddle
2003-06-04 17:21 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).