Junio C Hamano <gitster@xxxxxxxxx> 于2021年6月15日周二 下午12:46写道：
>
> Nicolas Pitre <nico@xxxxxxxxxxx> 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
