Re: prompt themes

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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