prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?

prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?

[Matthias Kopfermann]

Hi, zsh workers!

The fg, fg_bold associative array and bg and bg_bold in the
colors function are quite useful.

For _prompts_ i have to surround every variable with %{ %} which
does not , aehem, look too nice.
what do you think? would it be fine to have that with
wrapped around %{ %} , too so that not everybody has to put
these around the keys or roll a prompt_colors_array on his
own?

I think, i would love to be able to just use
PS1=$pbg[red]%~ ...
and it just works out of the box in every zsh.

Bad idea?

        Matthias

Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?

[Frank Terbeck]

Matthias Kopfermann <matthi@infodrom.north.de>:
> The fg, fg_bold associative array and bg and bg_bold in the
> colors function are quite useful.
> 
> For _prompts_ i have to surround every variable with %{ %} which
> does not , aehem, look too nice.
> what do you think? would it be fine to have that with
> wrapped around %{ %} , too so that not everybody has to put
> these around the keys or roll a prompt_colors_array on his
> own?
> 
> I think, i would love to be able to just use
> PS1=$pbg[red]%~ ...
> and it just works out of the box in every zsh.
> 
> Bad idea?

Not at all, IMHO.

I just think that the colors function would load quite a lot of
redundant information, if these are added as well. Maybe these
definitions could be added by a new function (e.g. prompt_colors).

Of course you could add code like:

[snip]
for i in ${(k)fg} ; do pfg[$i]="%{$fg[$i]%}" ; done
[snap]

to your .zshrc, but I guess a loadable function would be easier for
new users.

As an addition:
Today a user asked on IRC how to print out blinking text with the help
of the autoloadable colors function. I told him that, this would do:

[snip]
blink="\e[${color[blink]}m"
[snap]

Maybe it would be helpful to add this to the colors function:

[snip]
blink_color="$lc${color[blink]}$rc"
[snap]

Regards, Frank

Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?

[Bart Schaefer]

On Aug 18, 12:26pm, Matthias Kopfermann wrote:
}
} For _prompts_ i have to surround every variable with %{ %} which
} does not , aehem, look too nice.

The colors function is meant to be entirely separable from prompts, so
it avoids reference to any prompt formatting strings.

} what do you think? would it be fine to have that with
} wrapped around %{ %} , too so that not everybody has to put
} these around the keys or roll a prompt_colors_array on his
} own?

Another reason I resisted this is that it leads to PS1 values that
contain lots more %{ %} pairs than are often necessary.  E.g., for a
two-line prompt, you can often put the entire first line in a single
pair of %{ ... %}.

On Aug 18,  3:08pm, Frank Terbeck wrote:
}
} I just think that the colors function would load quite a lot of
} redundant information, if these are added as well.

That, too.

} [snip]
} for i in ${(k)fg} ; do pfg[$i]="%{$fg[$i]%}" ; done
} [snap]
} 
} to your .zshrc, but I guess a loadable function would be easier for
} new users.

Perhaps a candidate for adding to the zsh-newuser-install function?

} Maybe it would be helpful to add this to the colors function:
} 
} [snip]
} blink_color="$lc${color[blink]}$rc"
} [snap]

Hrm.  That would imply we ought to have $fg_blink and $fg_no_blink as
associative arrays as well, etc. ... this doesn't scale.  What's really
needed is a function that takes a set of attributes and turns them on
or off, but then you have to use $(...) which is ugly.  Of course even
then you have to maintain your own idea of the screen state, because
what you send to the terminal is "set the attributes to this" not
"change the attributes in this additive/subtractive way".

This seems like something to revisit when we have discipline functions
attached to parameter expansions.

readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Matthias Kopfermann]

On Fri, Aug 18, 2006 at 11:03:51AM -0700, Bart Schaefer:
> On Aug 18, 12:26pm, Matthias Kopfermann wrote:
> }
> } For _prompts_ i have to surround every variable with %{ %} which
> } does not , aehem, look too nice.
> 
> The colors function is meant to be entirely separable from prompts, so
> it avoids reference to any prompt formatting strings.

yes, i see that is not a good idea then.

> Another reason I resisted this is that it leads to PS1 values that
> contain lots more %{ %} pairs than are often necessary.  E.g., for a
> two-line prompt, you can often put the entire first line in a single
> pair of %{ ... %}.

if one only uses one color , you mean?
perhaps i was mistaken to think that every escape code needs
needs these %{ %} around it.
so i thought it really had to be done  with any new one.

> } [snip]
> } for i in ${(k)fg} ; do pfg[$i]="%{$fg[$i]%}" ; done
> } [snap]
> } 
> } to your .zshrc, but I guess a loadable function would be easier for
> } new users.
> 
> Perhaps a candidate for adding to the zsh-newuser-install function?

That wouuld really be nice!

The biggest problem in zsh functions is readability
already. As much as i love zsh features and what pleasure
they bring to console life i think that these already come
with a very big cost: and that is very bad readability.
Nearly every line in /usr/share/zsh/*/functions is so
stuffed that it needs much concentration to understand what
it's doing. So much, that i sometimes think of using m4 to
use zsh features in shell programming and that is extremely alarming!
[ And does not at all help in reading other code ]

And prompt definitions belong in this category, too.

                Matthias

Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Bart Schaefer]

On Aug 19,  8:43am, Matthias Kopfermann wrote:
}
} > Another reason I resisted this is that it leads to PS1 values that
} > contain lots more %{ %} pairs than are often necessary.  E.g., for a
} > two-line prompt, you can often put the entire first line in a single
} > pair of %{ ... %}.
} 
} if one only uses one color , you mean?

No; if you have a two-line prompt.  The first line of the prompt makes
no difference at all to the length of the line where zle will be editing,
so you can do

PS1=$'%{whole first line with all sorts of color changes\n%}nextline% '

In fact now that I think of it zle may be smart enough to ignore all
the stuff before the newline, in which case you don't need the %{ %}
at all on that line.

} perhaps i was mistaken to think that every escape code needs
} needs these %{ %} around it.
} so i thought it really had to be done  with any new one.

Think of it in terms of cursor motion.  You need %{ when the cursor
stops moving and %} when it starts again, and in between you can do
anything you like (including sending the cursor off to some other
part of the screen, as long as you bring it back to the original spot
again before closing the braces).  You also need %{ and %} only as
they affect the same screen line where the prompt finally finishes,
because zle only cares about horizontal position, not vertical.

} The biggest problem in zsh functions is readability

You mean in cryptic sytax for parameter expansions and format strings.
Yes, in many ways shells are a throwback to the days when the number
of bytes or keystrokes used made a large difference, and interpreters
could not compile and call user-defined functions for things like
prompts and string manipulation.  Also the requirement for using the
unix stdin/stdout pipe model for text manipulation made it much more
efficient to build things into the shell syntax that would have been
better handled externally.

Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Matthias Kopfermann]

On Sat, Aug 19, 2006 at 11:39:25AM -0700, Bart Schaefer:
> } perhaps i was mistaken to think that every escape code needs
> } needs these %{ %} around it.
> } so i thought it really had to be done  with any new one.
> 
> Think of it in terms of cursor motion.  You need %{ when the cursor
> stops moving and %} when it starts again, and in between you can do
> anything you like (including sending the cursor off to some other
> part of the screen, as long as you bring it back to the original spot
> again before closing the braces).  You also need %{ and %} only as
> they affect the same screen line where the prompt finally finishes,
> because zle only cares about horizontal position, not vertical.

This was very helpful to me as I did not consider color to
be a cursor motion but i know that ansi escapes include
those.
I do remember seeing the effect of bad cursor movement in bash 1
when programming my PS1-prompt :) and when i ever forget to use
%{ %} at zsh PS1 once more. :)

> } The biggest problem in zsh functions is readability
> 
> You mean in cryptic sytax for parameter expansions and format strings.

The lack of white space is something i really suffer in
specific zsh features often and the abundance of
tooooooooooo long lines.
That makes reading so exhausting and I know it's not only me!

Functions to having done many of these nice builtin features like splitting, joining, uppercasing e.g.
would have had a much better effect on readability.  Instead
it's done using modifiers. Variables nestings have to be
blamed for much of the rest.

What would I lose if I was not to go the dirty nesting way
but assign to the same variable once again?
When would I really suffer from efficiency lack? Ever?
My only other help are continuation lines.

                Matthias

Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Bart Schaefer]

On Aug 20,  8:56am, Matthias Kopfermann wrote:
}
} > Think of it in terms of cursor motion.
} 
} This was very helpful to me as I did not consider color to
} be a cursor motion

Well ... it isn't.  It's a sequence of bytes that are sent to the
terminal but that do not move the cursor.  Hence %{ when the cursor
has stopped, send output that doesn't affect the position, and then
%} when the subsequent output will affect the position again.

} The lack of white space is something i really suffer in
} specific zsh features

That's an inescapable side-effect of the long-ago decision (made long
before zsh was even thought of) to define the shell grammar in terms
of splitting the input at whitespace.

} often and the abundance of tooooooooooo long lines.

If you're referring to the completion functions, most of those went
through several iterations with the operations spread across several
assignments and then were optimized by collapsing them once it was
felt that the function was finished and only the developers would
ever need to look at it again.

} Functions to having done many of these nice builtin features like
} splitting, joining, uppercasing e.g. would have had a much better
} effect on readability.

As I said before, that limits one to using the stdin/stdout model for
passing text around.  Or one could pass parameter names as arguments,
as a poor substitute for references.  Given the choice of

	upper=${(U)lower}
	toupper -i lower -o upper
	upper=$(toupper $lower)

the first of those is both most efficient and most primitive -- that
is, you can write either of the other two in terms of the first one,
but the opposite is not true.

	function toupper {
	  local -A opts
	  zparseopts -D -A opts i: o:
	  if (( $+opts[-o] ))
	  then
	    # Note, this fails for array outputs, needs work
	    typeset -g ${opts[-o]}="${(UP)opts[-i]:-$*}"
	  else
	    print -R "${(UP)opts[-i]:-$*}"
          fi
        }

} What would I lose if I was not to go the dirty nesting way
} but assign to the same variable once again?

For one thing, you lose the original value of the parameter, so you
can't later manipulate it some other way.

OK, so assign it to some second temporary parameter.  Every assignment
uses three to four times as much memory as required for just storing
the value, plus several passes of something slightly slower than a
strcpy() to move the value through that memory.  A nested expansion
cuts that roughly in half (it depends on what you're doing).

} When would I really suffer from efficiency lack? Ever?

Again it depends on what you're doing.  If you're processing several
thousand lines of text, you might suffer a lot.

These are all general problems with the shell language and the way its
interpreters are required to behave.  Zsh's internals could do better
than they do, but the opportunities for, e.g., passing a parameter by
reference instead of by expanding its value, are greatly limited by the
imposed semantics.  Piling on syntactic hints is the only way to get
around this.  Remember, the base technology of unix shells is at least
25 years old now, and if you want a clean language you'll have to start
from something a little more recent.

Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Matthias Kopfermann]

[ .. long wise explanation of Bart Schaefer, I will keep at
my desk :) ]

thx , bart. it makes things really clearer for me.
Your kind ways of explaining it to the dumb [ yours truely ]
made/makes me stay for many years in ZSH-land as a much
happier user!

                Matthias