bug#33796: 27.0.50; Use utf-8 is all our Elisp files

[Paul Eggert <eggert@cs.ucla.edu>]

On 12/20/18 8:06 AM, Eli Zaretskii wrote:

 > my opinion should also count, right?

Of course, although my impression was that you weren't expressing an 
opinion and were soliciting opinions. If your opinion is that we should 
not make the change, then of course that counts.

 > we need the opinion of people
 > who might be actually affected by the proposed change,

I assume you mean that we need the opinion of people who would be 
affected _negatively_. Stefan and I would actually be affected 
_positively_ by the proposed change, for the reasons we stated.

 > All 3 of us simply don't care,

No, actually I do care. Non-UTF-8 source files are a real annoyance for 
me, on a fairly regular basis. Stefan seems to care too, though I 
suspect he doesn't care as much as I do.

 >  . Displaying HELLO doesn't show "gibberish", it shows UTF-8 encoded
 >    text with pure-ASCII markup.

You're right. My apologies: when I wrote "gibberish" I was looking at 
the output of "git diff emacs-26..master etc/HELLO", which does indeed 
display gibberish but that's not the current encoding's fault.

 > But since in your opinion the current situation is a
 >    "disaster", you seem to be saying that we should go back to ISO-2022?

Not at all, but I do think we should cut down on the unnecessary markup 
in that file. The markup should be used only when it helps. Text like 
"<x-charset><param>mule-unicode-0100-24ff</param> </x-charset>" is not 
helping anybody; the file should just contain " " there. Most of the 
markup in that file is not necessary for proper display, and just gets 
in the way when using tools other than Emacs.

 >  . By the above reasoning, if Emacs is enhanced to interpret HTML/XML
 >    and show typefaces instead of markup, you will see that as a
 >    regression and complain that raw HTML files are "gibberish"?

I hope Emacs doesn't do any such thing by default. I often use Emacs to 
edit .html and .xml files, and if it attempted to render these files by 
default I would be inconvenienced. Presumably there would be an option 
to keep the old behavior, and I'd use that option.

 >  . You have find-file-literally to show you HELLO exactly as any
 >    text-mode tool will see it

No, because find-file-literally shows hard-to-read stuff like this:

</x-charset><x-charset><param>greek-iso8859-7</param>Greek 
(\316\265\316\273\316\273\316\267\316\275\316\271\316\272\316\254) 
\316\223\316\265\316\271\316\254 \317\203\316\261\317\202

which differs from (and is even worse than) what an ordinary tool like 
git or cat shows:

</x-charset><x-charset><param>greek-iso8859-7</param>Greek (ελληνικά)   
Γειά σας

It would be better to remove this particular markup, so that git etc. 
would show this:

Greek (ελληνικά)    Γειά σας

which is what Emacs ordinarily shows.

 >  . No experience in Enriched mode is needed to edit HELLO, you just
 >    need to apply text properties (via facemenu.el commands or the
 >    menu-bar's Edit->Text Properties menu).  And these properties are
 >    optional.

Let's leave most of them out then, as they're not working well in 
etc/HELLO. I don't use that menu, but I took your hint and just now 
tried it, by selecting the abovementioned word "ελληνικά" and menuing to 
Edit > Text Properties > Describe Properties, but all it said was 'Text 
content at position 1530: There are text properties here: unknown 
("x-charset")'. This missed the point that the word's character set is 
greek-iso8859-7 which is a special hack that hints to Emacs (and nobody 
else, I guess? I couldn't find documentation for this stuff even in the 
Emacs manuals) that the text should be displayed with a Greek font 
instead of the same Greek font that Emacs would be using anyway. And I 
didn't see an easy way to see visually that the this (unnecessary) 
<x-charset> hint is misplaced, since it should be placed so that it 
applies only to the Greek text and not to the surrounding English text 
in the same line.