Re: prompt themes

[Dirus <Dirus@xxxxxxxxxxxxxx>]

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