Re: [PATCH] prompt: support generic non-visible regions

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Thu, Aug 11, 2022 at 9:02 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> On 8/10/22, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> > On Wed, Aug 10, 2022 at 1:59 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:

> >> The commit message seems a bit confused, %F has nothing to do with
> >> marking characters as 0-width, rather everything between %{ and %}
> >> will be treated as such. You can use %{%} (or \001 https://www.logicallyfallacious.com/logicalfallacies/Slippery-Slopeand \002) to set
> >> colors via the specific \e [ Ps m code, but also to send any other
> >> codes handled by the terminal.
> >
> > If I do PS1='%F{red}foo' putpromptchar() will call
> > set_colour_attribute(), which eventually calls this:
> >
> >   if (!bv->dontcount) {
> >       addbufspc(1);
> >       *bv->bp++ = Inpar;
> >   }
> >   tputs(tgoto(tcstr[tc], colour, colour), 1, putstr);
> >   if (!bv->dontcount) {
> >       addbufspc(1);
> >       *bv->bp++ = Outpar;
> >   }
> >
> > I can do the same thing fputs() is doing with PS1=$'\e[31mfoo', but
> > now zsh will think my prompt is bigger than it actually is and the
> > shell will be screwed. So I have to put that inside %{%}.
> >
> > Therefore "%F{red}" = $'%{\e[31m%}'
>
> Sure, this agrees 100% with what I was saying, but the statement in
> the commit still doesn't make sense. You've proven that you can use %{
> or \001 to do what %F{} does, but the commit message states the
> opposite which is not true.

The commit message says:

1. We do readline $'\001\e[31m\002' as zsh '%F{red}'.

This is true.

2. We could support $'\001\e[31m\002'.

This is also true.

> >> That aside, I don't really see a reason to add support for
> >> bash-specific prompt sequences that are more cumbersome to use than
> >> the already existing zsh ones. Bash prompts are already completely
> >> incompatible anyway.
> >
> > The prompts are not compatible, but the functions used in those prompts can
> > be.
> >
> >   __git_ps1_test () {
> >     local branch='master'
> >     local red=$'\001\e[31m\002'
> >     local clear=$'\001\e[m\002'
> >     echo "${red}${branch}${clear}"
> >   }
> >
> > The function above works perfectly fine in bash and zsh with my patch,
> > and I can add $(__git_ps1_test) to both of my prompts.
>
> You could also have a $START_INVIS and $END_INVIS parameter depending
> on what shell you're in.

Yes, and I can do red=$'\001\e[31m\002' or red='%F{red}' depending
what shell I'm in, which is what I was doing.

But *why* would I do that when zsh is perfectly capable of
interpreting \001 and \002? (with my patch)

> Well, I don't have a strong opinion either
> way, but it doesn't seem worth it to me. If we support this, people
> might ask "but you support \001, why not this other xyz prompt feature
> from bash?"

Slippery slope fallacy [1]. Yes, they might ask that, and you might
answer "no, unline \001, xyz requires too much effort".

This doesn't require too much effort.

[1] https://www.logicallyfallacious.com/logicalfallacies/Slippery-Slope

-- 
Felipe Contreras