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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, 33796@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 19 Dec 2018 14:13:59 -0800
> 
> On 12/19/18 10:11 AM, Eli Zaretskii wrote:
>  > I need to hear a second opinion,
> 
> That would actually be a third opinion, as Stefan's opinion surely 
> counts too and he has good reasons to prefer UTF-8 here.

Technically, it's the forth, because my opinion should also count,
right?

But this is besides the point, because we need the opinion of people
who might be actually affected by the proposed change, and none of us
qualify.  All 3 of us simply don't care, because we don't read these
scripts and don't distinguish the various fonts used to display the
same Unicode codepoints under different cultural conventions.  At some
point in the past that distinction was very important.  If nowadays it
no longer is, then I see no problems making the change.  Otherwise,
the change will lose information important to some of our users.

We need someone to advise us what is the actual state of the affairs.
I hope Handa-san will (please don't drop him from the CC list).  Or
maybe someone here can propose other experts or even just users with
relevant experience.

> And to some extent opinions should be weighted for the kind of
> maintenance that is actually done with these files as opposed to the
> rare cases where the font's style might annoy a language-expert
> developer if the wrong language environment were used.

This is also beyond the point, because we have nothing to weigh this
against for now.  When we do, we will.

>  >> etc/HELLO is pretty much a disaster for me now, as I can’t use any tool
>  >> other than Emacs to look at it
>  >
>  > ??? It's a UTF-8 file with markup.  Do you have the same problems with
>  > HTML and XML files?
> 
> No, because when I visit those files I see the same thing in my Emacs 
> editing buffer that I see after using common keystrokes like 'C-x v =' 
> or standard tools like "git diff", and it's easy to use Emacs to edit 
> these files in the usual way without becoming expert in html-mode etc. 
> In contrast, with etc/HELLO standard tools and common keystrokes give me 
> gibberish, and one must gain expertise in enriched-mode to make 
> nontrivial changes.

This line of reasoning makes little sense to me:

 . Displaying HELLO doesn't show "gibberish", it shows UTF-8 encoded
   text with pure-ASCII markup.  If your terminal can display these
   characters, you should see legible marked-up text, whereas the
   ISO-2022 encoded file of yore would display as illegible escape
   sequences.  But since in your opinion the current situation is a
   "disaster", you seem to be saying that we should go back to
   ISO-2022?
 . 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"?
 . You have find-file-literally to show you HELLO exactly as any
   text-mode tool will see it, if you really need that.
 . 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.

> A primary goal of Emacs is to have source code that the user can change 
> easily, and using enriched-text mode in etc/HELLO works against this. It 
> might be OK just for that one file (as a demonstration of enriched-text 
> mode perhaps) but as things stand we shouldn't let these issues infect 
> the rest of the Emacs sources.

etc/HELLO is not a demonstration of Enriched mode, it is a
demonstration of facilities to edit and display many different scripts
and character sets in the same buffer.  We use Enriched mode there
because we have no other feature which allows us to save 'charset'
text property to a disk file.