On Thu, Dec 10, 2020 at 09:30:39PM +0100, Christian Weisgerber wrote:
> Stefan Sperling:
> 
> > The "problem" is that this log message contains \r\n line endings.
> > Quick and simple fix below. OK?
> > 
> > diff 9a2d6ca19c544d6f55347ccb18c566434f6f8d4c ac7edcfb7479cb3379bc90df5540e8d9565ea7bf
> > blob - 457fcc6885530f6eb53c478998fd277562f91f45
> > blob + ee044a71602208bed395a517f0354d580be3407f
> > --- tog/tog.c
> > +++ tog/tog.c
> > @@ -1164,6 +1164,15 @@ format_line(wchar_t **wlinep, int *widthp, const char 
> >  	if (err)
> >  		return err;
> >  
> > +	if (wlen > 0 && wline[wlen - 1] == L'\n') {
> > +		wline[wlen - 1] = L'\0';
> > +		wlen--;
> > +	}
> 
> Where would trailing newlines come from?
> Not from a log message, since fparseln will split them up.

I plan to switch from fparseln(3) to getline(3) eventually, which
will keep \n intact. (This patch was extracted out of a larger
patch that converts tog to getline(3), which isn't finished yet.)

> > +	if (wlen > 0 && wline[wlen - 1] == L'\r') {
> > +		wline[wlen - 1] = L'\0';
> > +		wlen--;
> > +	}
> > +
> 
> That makes sense, I guess.
> 
> It made me curious how got & tog deal with terminal control sequences
> in commit messages and blobs.
> * got log just passes them through to the terminal--as does git.
> * tog escapes them (where??), but gets confused about the line length.

Likely happens when tog converts to wide charactors so ncurses can
display UTF-8 text? Non-UTF-8 data gets run through strvis in mbs2ws().