> > Besides, based on the actual binary representation of UTF-8, it's
> > extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm
> > already does this: UTF-8 it handles natively, but open up one of these
> > unpatched files in VIm and you'll see "[converted]" at the bottom of your
> > screen. Should happen if you open the attached .patch.bin file in VIm.
>
> Yes, I agree that heuristics can be used to determine the coding
> system used with a high degree of probability. I'm just suggesting we
> make the coding system explicit, in order to spare other applications
> that do visual presentation of Linux source code having to perform
> their own heuristics.
>
> But hey, if I'm the only one wanting to see this particular bike shed
> painted blue...
In any other case, I would agree completely, but like I said, the entire
tree will be one encoding anyway, which will be UTF-8. Many tools would
already have these heuristics, and even if they don't, the code itself
will be perfectly legible no matter which encoding is used to view it, and
only some things like circuit diagrams and peoples' names may be slightly
mangled. Any byte which is 0x7F or less is identical in both encodings, so
all normal ASCII is unchanged.
It's an issue only in transition. No new non-UTF-8 patches should be
accepted, of course. And I won't be doing any changes that break anything
other than a live person reading it and wondering why it looks weird if
they don't have the right tools.
A line in <Documentation/CodingStyle> explicitly requiring UTF-8 sounds
like a good idea. I shall submit one later if I remember. Many mail
clients do this conversion automatically, which causes me headaches and
requires me to attach the patches separately. Quite annoying really. I'm
exploring the possibility of hacking together a simple SMTP client if
that'll help me with these fool binary patches.
Or maybe setting up a little mini git repository with UTF-8 changes is a
good idea? Hmm, I'll research that, and try it. Then I could just cc it to
trivial and the list and they can just pull it in one go. One more week
until summer vacation! I shall have time to do this then.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
