From: kai.grossjohann@gmx.net (Kai Großjohann)
Subject: Re: 8859 unification and Emacs' ChangeLog files
Date: Thu, 03 Apr 2003 18:50:16 +0200 [thread overview]
Message-ID: <8465pvo793.fsf@lucy.is.informatik.uni-duisburg.de> (raw)
In-Reply-To: 200303310045.JAA14857@etlken.m17n.org
Kenichi Handa <handa@m17n.org> writes:
> In article <848yuy3xab.fsf@lucy.is.informatik.uni-duisburg.de>, kai.grossjohann@gmx.net (Kai Großjohann) writes:
>> I've learned the hard way that unify-8859-on-decoding-mode mangles
>> Emacs' ChangeLog files. Now Simon (see Cc) has shown me that it is
>> possible to turn unification off for certain encodings.
>
>> Do you think it might be good to turn it off for iso-2022-7bit?
> [...]
>> Simon's Lisp was: (coding-system-put 'iso-2022-7bit
>> 'translation-table-for-decode (make-translation-table))
>
> Yes, it works because it overrides the translation table
> created by unify-8859-on-decoding-mode.
>
> But, it results in that a Latin-2 char read by iso-2022-7bit
> is different from what read by iso-latin-2. I don't think
> such a change is a good idea.
Well, without unification, a Latin-2 character read from a Latin-1
file is different from the same character read from a Latin-2 file.
>> Maybe that would make it possible to turn unify-8859-on-decoding-mode
>> on by default?
>
> It will stop unibyte<->multibyte automatic conversion in any
> single byte lang. env. (e.g. Latin-X, Greek) except for
> Latin-1.
What do you mean by "it"? Do you mean unify-8859-on-decoding-mode
generally, or do you mean unify-8859-on-decoding-mode with Simon's
add-on?
> I think unify-8859-on-decoding-mode is still only for those
> people who knows the consequence of the command well.
I know that unify-8859-on-decoding-mode is harmful for Emacs'
ChangeLog files, because they distinguish between the various
iso-8859 charsets.
But if all Emacs developers enable unify-8859-on-decoding-mode, then
this is not a problem anymore. Or the ChangeLog files could be
stored as UTF-8.
Of course, there might be other files where iso-8859 characters might
be present in different encodings. Is it right to say that these
files must be encoded in iso-2022 or in emacs-mule, because no other
encodings distinguish between Latin-1 ä and Latin-2 ä, say?
If I understand correctly, Emacs 22 will automatically unify all
iso-8859 charsets, so the same ChangeLog problem will occur there,
right? Or is Emacs 22 going to enable distinguishing between Latin-1
ä and Latin-2 ä for iso-2022 files somehow?
It seems that Europeans are really interested in more 8859
unification. Now that unify-8859-on-encoding-mode is on by default,
they are somewhat happier. But even with this enabled, people in a
Latin-9 locale can't search UTF-8 files well: when they hit the ä key,
they are searching for a Latin-9 ä whereas there is a Latin-1 ä in the
buffer. Or take me, personally: I use the german-prefix input method
which produces Latin-1 characters, but I'm running in a Latin-9 locale
so that the buffers contain the `wrong' characters.
At the moment, I tell them that I don't turn on
unify-8859-on-decoding-mode because then I can't edit the Emacs
ChangeLog files anymore.
If any of the previous message sounds weird, that might be because I
fail to fully grok the problem. I apologize. I'm looking at it from
a European point of view, so I might miss important points.
--
A preposition is not a good thing to end a sentence with.
next prev parent reply other threads:[~2003-04-03 16:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-29 17:19 8859 unification and Emacs' ChangeLog files Kai Großjohann
2003-03-31 0:45 ` Kenichi Handa
2003-04-03 16:50 ` Kai Großjohann [this message]
2003-04-03 18:38 ` Stefan Monnier
2003-04-03 20:38 ` Jason Rumney
2003-04-03 20:52 ` Jason Rumney
2003-04-04 12:58 ` Kai Großjohann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8465pvo793.fsf@lucy.is.informatik.uni-duisburg.de \
--to=kai.grossjohann@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).