Re: [PATCH v2 3/4] sideband: append suffix for message whose CR in next pktline

[Jiang Xin <worldhello.net@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2021年6月15日周二 下午12:46写道：
>
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Tue, 15 Jun 2021, Jiang Xin wrote:
> >
> >> The issue this patch try to fix is like the following example:
> >>
> >>     PKTLINE(\2 "<progress-1>" CR "<progress-2>")
> >>     PKTLINE(\2 CR "<message-3>" LF)
> >>
> >> The message "<progress-2>" is displayed without a proper clear-to-eol
> >> suffix, because it's eol (CR) is in another pktline.
> >
> > I'd fix this issue with the following logic:
> >
> > bool pending_clear_to_eol;
> >
> > my_putchar(c) {
> >       switch (c) {
> >       case '\r':
> >       case '\n':
> >               pending_clear_to_eol = true;
> >               break;
> >       default:
> >               if (pending_clear_to_eol) {
> >                       clear_to_eol();
> >                       pending_clear_to_eol = false;
> >               }
> >               break;
> >       }
> >       putchar(c);
> > }
> >
> > In other words, you clear the line after printing "remote:" but only if
> > there is a non \n or \r coming next.
>
> What puzzles me the most in this discussion is why we do this for
> LF.  I do understand why we need it for CR---the line we are going
> to show message on after emitting CR would be full of leftover
> letters we previously have written before emitting CR, so we'd show
> the message (to overwrite the initial part enough to show our own
> message) and then clear to the end with either ANSI sequence of
> sufficient number of whitespaces.  But line feed would take us to a
> fresh and blank line---there is nothing to clear, no?

I guess this may because sideband #2 messages are printed on the
screen in a background process, it never know a line where it starts
to print has characters on the right.  So it is safe to write an
additional clear-to-eol suffix no matter the message ends with CR or
LF.

--
Jiang Xin