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 12:38:50 -0700
> 
> For example, currently etc/HELLO has a charset transition in the middle of the 
> Maltese word “Bonġu”. If somebody actually specified a different font for 
> iso-8859-3 because they wanted to display Maltese+Esperanto differently from 
> English etc. (which as you note is unlikely, but suppose someone does it anyway 
> to show off this Emacs feature), then their display would be glitched up in the 
> middle of “Bonġu”. So as things stand this is a lurking bug in etc/HELLO. If we 
> omitted needless charset transitions we wouldn't have to worry about correcting 
> bugs like this one.

That's the bad part of the ISO-2022 legacy: the charset transitions
don't always make sense.  It should be easy to fix this, though, by
placing the charset properties on complete greetings rather than on
more or less arbitrary substrings.

> > 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.
> 
> Thanks, I wasn't aware of this issue. I don't see a bug report for it; should I 
> add an enhancement request?

Fine by me, but Emacs lacks good support for language-specific
handling of text in general.  We had a few discussions in the past
about that.

> In the meantime how about if we mark up etc/HELLO with lang commands instead of 
> x-charset commands, except that we also keep x-charset commands that actually 
> affect Emacs display in common use (e.g., CJK charsets)? When we get lang 
> working, we can then remove the remaining x-charset commands.

I'd rather we first fixed the charset properties coverage in the file
so that they make more sense.