Re: Prompt themes

Re: Prompt themes

[Clemens Fischer]

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

prompt themes

[Dirus]

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

Re: prompt themes

[Oliver Kiddle]

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.

Re: prompt themes

[Dirus]

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 

Re: prompt themes

[Oliver Kiddle]

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

Re: prompt themes

[Bart Schaefer]

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.