Erik Faye-Lund <> writes:

> But isn't UTF-8 constructed to be very unlikely to clash with existing
> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
> simply writes the byte as a hex-tuple?

If it's non-ascii and non-UTF-8, I think you'd want to display the byte
as it is, because this is how it was entered. IOW, I'd say we should
keep the current behavior in this case.

>> 2) The non-ascii sequence is NOT valid UTF-8, then if I read correctly
>>    (I didn't test) utf8_width would set next to NULL, and then you are
>>    in big trouble.
> Outch. Yeah, you are right; this is not good at all :)
> But I guess the solution above should fix this as well, no?

It should, yes.

Of course, there's still the case where the user entered "git -é" as a
à followed by a © in a latin-1 environment, but as you said, it's
unlikely enough ;-).

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to