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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 8/11/22, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> 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
>> >> \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.

The statement is true, but it's not what the commit message says, it says:
"readline assumes anything between \001 (start of header) and \002 (start
of text) is non-visible characters.

In zsh we do this with `%F{color}`"

I don't know why you are arguing about this, there's nothing bad about
fixing an error in a commit message after someone points it out.

> 2. We could support $'\001\e[31m\002'.
>
> This is also true.

That's true.

-- 
Mikael Magnusson