Re: Encoding of etc/HELLO

[Eli Zaretskii <eliz@gnu.org>]

> Cc: mwd@md5i.com, michael.albinus@gmx.de, handa@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 19 May 2018 11:23:01 -0700
> 
> Eli Zaretskii wrote:
> 
> > What do you mean by "unified" here?
> 
> What I meant was that, as far as I know, in Emacs this font selection currently 
> does not depend on whether the charset is latin-iso8859-1 or latin-iso8859-3, 
> because in UTF-8 text those two charsets are always displayed the same way that 
> text sans charsets is displayed.

The codepoints are unified, of course, but that's not the whole story
as far as font selection goes.  See the documentation of
set-fontset-font, where it says that you can define a certain font to
be used for a specific charset: the charset information comes from the
text property.

> And given the way the world has moved, it's hard to imagine any
> future version of Emacs caring whether the charset is
> latin-iso8859-1 or latin-iso8859-3 in UTF-8 text.

Emacs doesn't care, but users might.  I agree that it is unlikely in
European cultures, but it isn't impossible.  And what do we lose by
leaving the information in the file?

> > The 'charset' property just tells Emacs to which "culture", so-called,
> > or, if you want, to which language the greeting belongs
> 
> RFC 1896 specifies the 'lang' command to specify languages. Shouldn't etc/HELLO 
> do that instead of using 'charset'? That would seem to match the intent of 
> text/enriched better.

We need to have the corresponding property in Emacs first, and we need
to have infrastructure for letting 'lang' affect what we want it to
affect, at least font selection.  Only after that we can implement
this in enriched.el.  I stuck with 'charset' because all the necessary
infrastructure is already in place.  Yes, 'charset' is ISO-2022
legacy, but it doesn't mean it's necessarily useless in modern Emacs.