Supporting %F{...} and %K{...} in Zsh 4.x

Supporting %F{...} and %K{...} in Zsh 4.x

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Hi,

Does anyone have any better ideas on how to support %F / %f and %K / %k 
in Zsh 4.2.5?

I'm trying to use a consistent profile ~> PROMPT across multiple 
versions of Zsh.  (Common ~/.zshrc which source OS and host specific 
files at the end.)  This angst comes from an ancient FreeBSD system 
that's still out to pasture.

The hack that I put in place on the machine specific file is to set 
PROMPT and RPROMPT to values of themselves with global substitutions.

The difference between ${...:/.../...} in 5.9 and ${...//.../...} in 4.2 
was unexpected, but I got around that.

Does anyone have any better idea(s)?

export PROMPT=${PROMPT//\%f/%{^[[39m%}}
export PROMPT=${PROMPT//\%F{black}/%{^[[30m%}}
export PROMPT=${PROMPT//\%F{red}/%{^[[31m%}}
export PROMPT=${PROMPT//\%F{green}/%{^[[32m%}}
export PROMPT=${PROMPT//\%F{yellow}/%{^[[33m%}}
export PROMPT=${PROMPT//\%F{blue}/%{^[[34m%}}
export PROMPT=${PROMPT//\%F{magenta}/%{^[[35m%}}
export PROMPT=${PROMPT//\%F{cyan}/%{^[[36m%}}
export PROMPT=${PROMPT//\%F{white}/%{^[[37m%}}

export PROMPT=${PROMPT//\%k/%{^[[39m%}}
export PROMPT=${PROMPT//\%K{black}/%{^[[30m%}}
export PROMPT=${PROMPT//\%K{red}/%{^[[31m%}}
export PROMPT=${PROMPT//\%K{green}/%{^[[32m%}}
export PROMPT=${PROMPT//\%K{yellow}/%{^[[33m%}}
export PROMPT=${PROMPT//\%K{blue}/%{^[[34m%}}
export PROMPT=${PROMPT//\%K{magenta}/%{^[[35m%}}
export PROMPT=${PROMPT//\%K{cyan}/%{^[[36m%}}
export PROMPT=${PROMPT//\%K{white}/%{^[[37m%}}

export RPROMPT=${RPROMPT//\%f/%{^[[39m%}}
export RPROMPT=${RPROMPT//\%F{black}/%{^[[30m%}}
export RPROMPT=${RPROMPT//\%F{red}/%{^[[31m%}}
export RPROMPT=${RPROMPT//\%F{green}/%{^[[32m%}}
export RPROMPT=${RPROMPT//\%F{yellow}/%{^[[33m%}}
export RPROMPT=${RPROMPT//\%F{blue}/%{^[[34m%}}
export RPROMPT=${RPROMPT//\%F{magenta}/%{^[[35m%}}
export RPROMPT=${RPROMPT//\%F{cyan}/%{^[[36m%}}
export RPROMPT=${RPROMPT//\%F{white}/%{^[[37m%}}

export RPROMPT=${RPROMPT//\%k/%{^[[49m%}}
export RPROMPT=${RPROMPT//\%K{black}/%{^[[40m%}}
export RPROMPT=${RPROMPT//\%K{red}/%{^[[41m%}}
export RPROMPT=${RPROMPT//\%K{green}/%{^[[42m%}}
export RPROMPT=${RPROMPT//\%K{yellow}/%{^[[43m%}}
export RPROMPT=${RPROMPT//\%K{blue}/%{^[[44m%}}
export RPROMPT=${RPROMPT//\%K{magenta}/%{^[[45m%}}
export RPROMPT=${RPROMPT//\%K{cyan}/%{^[[46m%}}
export RPROMPT=${RPROMPT//\%K{white}/%{^[[47m%}}

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Roman Perepelitsa]

On Sun, Dec 17, 2023 at 8:43 PM Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> Hi,
>
> Does anyone have any better ideas on how to support %F / %f and %K / %k
> in Zsh 4.2.5?

How would you write your .zshrc if the only version of zsh that it had
to support was 4.2.5? Once you figure that out, you are done, for this
config will very likely work with any zsh version past 4.2.5.

Roman.

P.S.

Don't export PROMPT or any other internal zsh parameters.

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On 12/17/23 14:02, Roman Perepelitsa wrote:
> How would you write your .zshrc if the only version of zsh that it 
> had to support was 4.2.5? Once you figure that out, you are done, 
> for this config will very likely work with any zsh version past 4.2.5.

The config was created in contemporary 5.x Zsh and taken backwards.

I'll have to test a lot more things to see if everything else is compatible.

I really prefer using the color names with %F{...} and %K{...} and 
dislike using the terminal control codes as they are annoying to work 
with an maintain.

I guess I could set the color codes in variables and use the variables.

> P.S.
> 
> Don't export PROMPT or any other internal zsh parameters.

Please elaborate on this, particularly the down side of doing this.



-- 
Grant. . . .


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Roman Perepelitsa]

On Sun, Dec 17, 2023 at 9:51 PM Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> I'll have to test a lot more things to see if everything else is compatible.

I suppose you would want to do that in any case.

> I really prefer using the color names with %F{...} and %K{...} and
> dislike using the terminal control codes as they are annoying to work
> with an maintain.
>
> I guess I could set the color codes in variables and use the variables.

Right, you need to figure out how to write a functional and
maintainable config for zsh 4.2.5, which lacks many niceties
introduced in later versions.

> On 12/17/23 14:02, Roman Perepelitsa wrote:
> > Don't export PROMPT or any other internal zsh parameters.
>
> Please elaborate on this, particularly the down side of doing this.

Exported parameters become a part of the process' environment, which
gets inherited by all child processes. You don't want internal zsh
parameters to be inherited by child processes. In the best case it'll
do nothing, in the worst case it'll break things. To experience the
latter, export PS1 and run `bash --norc`. Notice the broken prompt.

On Sun, Dec 17, 2023 at 10:33 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> Why not just something like:
>
> if [[ "${(%):-"%F{red}%f"}" = *red* ]]
> then PROMPT=$'This is an %{\e[31m%}old%{\e[39m%} shell %# '
> else PROMPT='This is a %F{red}new%f shell %# '
> fi

To clarify my earlier point: if both branches work and produce
identical prompt, you can keep just one of them. It's less code to
test and maintain. Branching is necessary only when neither branch
works in all situations or when they have functionally distinct
effects.

Roman.

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On 12/18/23 00:57, Roman Perepelitsa wrote:
> I suppose you would want to do that in any case.

Reluctantly, yes.

But also, no.

The ancient FreeBSD 4.11 system that this was on croaked with a hard 
drive failure last night.  My friend, who owns the system, decided that 
there wasn't anything worth reviving the system for.  So ... this sort 
of turns into an academic exercise now.

I find myself having a reoccuring reaction to many of the following 
statements.  I know that you're correct.  But I don't like what it 
means.  I'm going to go kick dirt for a few minutes and come back.

> Right, you need to figure out how to write a functional and
> maintainable config for zsh 4.2.5, which lacks many niceties
> introduced in later versions.

I agree in concept.

> Exported parameters become a part of the process' environment, which
> gets inherited by all child processes. You don't want internal zsh
> parameters to be inherited by child processes. In the best case it'll
> do nothing, in the worst case it'll break things. To experience the
> latter, export PS1 and run `bash --norc`. Notice the broken prompt.

Hum.

I'd not thought about that before.  I have run into the very prompt 
issue that you're alluding to.

Is there a guideline for what should be exported and shouldn't be exported?

My primary concern is making sure that various preference are available 
where they need to be.

Or am I overcomplicating things by trying to pass things from one parent 
Zsh to a child Zsh when the child Zsh will initialize itself anew?

> To clarify my earlier point: if both branches work and produce
> identical prompt, you can keep just one of them. It's less code to
> test and maintain.

Occam's Razor & Parsimony

> Branching is necessary only when neither branch works in all situations 
> or when they have functionally distinct effects.

Valid distinction.

Very valid points.  #til  But I'm still pouting a little bit about what 
your correct statements mean.



-- 
Grant. . . .

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Sun, Dec 17, 2023 at 12:51 PM Grant Taylor <gtaylor@tnetconsulting.net>
wrote:

>
> I guess I could set the color codes in variables and use the variables.
>

Functions/Misc/colors from 5.9 (and even from git HEAD, currently) is
backward-portable to 4.2.x (again, tested on 4.2.6).

This may be useful:

coloresc() {
  local codes=$(printf "%s;" ${(e):-\$\{color\["$^@"\]?oops\}})
  REPLY=$'\e['"${codes%;}m"
}

Used like
  coloresc bg-bright-blue bold white
it sets $REPLY to the escape sequence for the listed color combination.

[-- Attachment #2: Type: text/html, Size: 1094 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Bart Schaefer]

On Sun, Dec 17, 2023 at 11:43 AM Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
>
> Does anyone have any better ideas on how to support %F / %f and %K / %k
> in Zsh 4.2.5?

That seems like an awful lot of work to go through for something that
doesn't change very often.  Why not just something like:

if [[ "${(%):-"%F{red}%f"}" = *red* ]]
then PROMPT=$'This is an %{\e[31m%}old%{\e[39m%} shell %# '
else PROMPT='This is a %F{red}new%f shell %# '
fi

I'm pretty sure $'...' works properly in 4.2.5, but the closest I can
test with is 4.2.6.  In sufficiently old zsh, even the parse of
"${(%):-"%F{red}%f"}" doesn't work.

> export PROMPT=${PROMPT//\%f/%{^[[39m%}}
> export PROMPT=${PROMPT//\%F{black}/%{^[[30m%}}
[...]

What Roman said RE "export".

Also there's no reason to re-export a parameter every time you change
it.  Once exported, always exported, unless "typeset +x" is used.

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On 12/17/23 15:32, Bart Schaefer wrote:
> That seems like an awful lot of work to go through for something that 
> doesn't change very often.

I think it changes more often than some think.  Particularly the RPROMPT 
where I have conditional color for ${?}; 0 is -- from memory -- a bright 
grey on black "[0]", while > 0 is a bright white on bright red "[#]" 
(where # is the value of ${?}).

> Why not just something like:
> 
> if [[ "${(%):-"%F{red}%f"}" = *red* ]]
> then PROMPT=$'This is an %{\e[31m%}old%{\e[39m%} shell %# '
> else PROMPT='This is a %F{red}new%f shell %# '
> fi

Because that's two PROMPT values to maintain (independent of the old vs 
new).  I'd rather have one version to maintain and for that version to 
be relatively easy to read and understand.

> I'm pretty sure $'...' works properly in 4.2.5, but the closest I 
> can test with is 4.2.6.  In sufficiently old zsh, even the parse of 
> "${(%):-"%F{red}%f"}" doesn't work.

I must be too tired as I'm not able to unpack what that does.  It seems 
as if it does something with "(%)" and uses "%F{red}%f" if the former is 
unset.  But I don't recognize "(%)".  :-(

> What Roman said RE "export".

ACK

> Also there's no reason to re-export a parameter every time you change 
> it.  Once exported, always exported, unless "typeset +x" is used.

Noted.

Thank you.

Today I Learned.



-- 
Grant. . . .

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Bart Schaefer]

On Tue, Dec 19, 2023 at 10:00 PM Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
>
> On 12/17/23 15:32, Bart Schaefer wrote:
> > That seems like an awful lot of work to go through for something that
> > doesn't change very often.
>
> I think it changes more often than some think.  Particularly the RPROMPT

So what are you planning to do, re-source your .zshrc every time it changes?

The plan to translate %F / %K just seems unworkable to me.

> where I have conditional color for ${?}; 0 is -- from memory -- a bright
> grey on black "[0]", while > 0 is a bright white on bright red "[#]"
> (where # is the value of ${?}).

OK, but you do that with the %(?.true.false) escape, right?  You're
not changing the actual assignment to PROMPT= every time?  The latter
is what I mean by "doesn't change very often" (if you're using nothing
but 4.2 features).

> > if [[ "${(%):-"%F{red}%f"}" = *red* ]]
>
> I must be too tired as I'm not able to unpack what that does.

(%) is a parameter expansion flag, it means "treat the rest of this
expansion like a prompt".

Using :- like that means "if the empty parameter name is unset" (which
is always the case).

So if %F is not supported in a prompt, that substitution will return
something containing the literal string "red" somewhere.

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

On 12/20/23 10:58, Bart Schaefer wrote:
> So what are you planning to do, re-source your .zshrc every time it changes?

No.

> The plan to translate %F / %K just seems unworkable to me.

It did function and I was getting identical behavior on the old and new 
systems.

At least until the drive in the ancient system died.  The owner has 
posthumously decided that the system didn't need to be retained.  Go figure.

So this is now an academic discussion.

> OK, but you do that with the %(?.true.false) escape, right?

Yes.

> You're not changing the actual assignment to PROMPT= every time?

PROMPT / PS1 and RPROMPT will be initialized with different values as 
the shell is started when opening a new terminal emulator, entering a 
nested shell, forking !shell from in vi(m) et al.

But you are correct that the dynamic nature of any invocation is via the 
%(?.true.false) form.

The contents of the PROMPT / PS1 / RPROMPT will likely not change in any 
given invocation of the shell.  But what those values output can be 
fairly dynamic.

> The latter is what I mean by "doesn't change very often" (if you're 
> using nothing but 4.2 features).

Fair enough.  I was thinking about the dynamic output of what you are 
considering to be the static input.

> (%) is a parameter expansion flag, it means "treat the rest of this
> expansion like a prompt".

Interesting.

> Using :- like that means "if the empty parameter name is unset" (which
> is always the case).

ACK

I make judicious use of that.  But I wasn't sure if it was the same with 
the "(%)" or if that fundamentally altered it.

> So if %F is not supported in a prompt, that substitution will return
> something containing the literal string "red" somewhere.
Hum.

This makes me wonder -- academically -- if I could create a bunch of 
variables that are effectively place holders for each color and then 
reference them in the prompt as necessary.  But doing so intelligently 
wherein if it's supported, use the %F{...} method or fall back to the 
manually entered control codes.  But I feel like that might be an 
abstraction inversion.  :-/

I'll probably poke at this at some point to make sure I truly understand 
what is possible and then evaluate if it's worth doing or not.  -- 
Sometimes there is merit to an abstraction inversion as it helps foster 
fuller understanding of some concepts as an academic exercise.

As for the system on the failed drive, I manged to do a full bare metal 
system recovery into a VM hours before the owner decided to decommission 
the system.  C'est la vie.

Thank you Bart and Roman, you've both given me things to think about as 
I reflect on and learn from this experience.  :-)



-- 
Grant. . . .

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

Re: Supporting %F{...} and %K{...} in Zsh 4.x

[Bart Schaefer]

On Sun, Dec 24, 2023 at 10:25 AM Grant Taylor
<gtaylor@tnetconsulting.net> wrote:
>
> This makes me wonder -- academically -- if I could create a bunch of
> variables that are effectively place holders for each color

That's what Functions/Misc/colors does.