unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.

  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).