Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
- From
Jeff King <peff@peff.net>
- Date
- Feb 2, 2009, 12:41 UTC
- Message-ID
- <20090202124139.GA8325@sigio.peff.net>
- In-Reply-To
- <7v8wopmizw.fsf@gitster.siamese.dyndns.org>
On Sun, Feb 01, 2009 at 10:48:51PM -0800, Junio C Hamano wrote:
Show 17 quoted lines
> > I do not know what encoding the author is at that point, but if you cannot > > be sure that it is UTF-8, using utf8_strwidth() is just as wrong as the > > current code, IMHO. > > That is true, but then we are not losing anything. > > This codepath is not about the payload (the contents of the files) but the > author name part of the commit log message, and UTF-8 would probably be > the only sensible encoding to standardize on. > > If your project uses UTF-8 for everybody, great, we will align them better > than we did before. If not, sorry, you will get a different misaligned > names. > > That assumes utf8_width() does not barf when fed an invalid byte sequence, > but I did not think it is that fragile (I didn't actually audit the > codepath, though).
We should be able to know the encoding (we call reencode_commit_message, but we don't bother to save the result). It should be trivial to do:
int strwidth(const char *s, const char *encoding)
{
if (!strcmp(encoding, "utf-8"))
return utf8_strwidth(s);
/* ideally, else if (some_other_encoding_family) */
else
return strlen(s);
}Then utf-8 is fixed, and other encodings keep identical behavior (and don't even waste cycles on utf-8 decoding). And it should be obvious to anyone who wants to add a width detector for their pet encoding where it should go.
-Peff