Re: the evil iso-accents-mode: babel does not work
Uwe Brauer wrote:
>>>>> "Andreas" == Andreas Roehler
<andreas.roehler(a)online.de> writes:
> Uwe Brauer wrote:
>>
> Hi Uwe,
> I'm interested in that matter too on the long run, maybe I join
> here your efforts.
Very welcome, I am meanwhile so desperate in the sense that I cannot
localise the errors, that I use indirect-buffers for the translation via
babel.
> As I'm not that familiar with XEmacs, please tell me, why do you
> use 21.4 still? Isn't it better to upgrade to 21.5?
Well I had problems with gnus and the impression that 21.5 is slower and
(but here I am not sure) that I also had problems with auctex.
> May your problem be solved with Unicode thoroughly?
The unicode for 21.5 is better than 21.4, however not complete (as is
GNU >=21)
However when I set
(set-default-coding-systems 'utf-8)
then things are worse!!!!
What really puzzles me is that iso-accents-mode is (almost) equivalent
to quail. That is not true for GNU emacs
For example typing
in GNU emacs
"a --> "a (iso-accents-mode) BUT
"a --> ä (quail-input german-prefix),
in xemacs 21 Mule
"a --> ä (iso-accents-mode)
"a --> ä (quail-input german-prefix),
So I don't know why iso-accents-mode screws up the coding in a
iso-8859-1 buffer!!!
Uwe
Hi Uwe,
do you really need iso-accents-mode?
It looks somehow outdated.
With buffer example code
,----
| % Local Variables:
| % buffer-file-coding-system: iso-8859-15
| % End:
|
| how to save œ other than utf8
`----
it works for me with GNU and XEmacs alike. Always fine after
reopening. Not so, if the local vars part is missing.
Thats with
GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version
2.12.0) of 2007-11-24 on dede
XEmacs 21.5 (beta28) "fuki" (+CVS-20070806) [Lucid] (i386-suse-linux, Mule)
of Sun Sep 23 2007 on verdi
So maybe it's done with updating?
If not, what Steve explained indicates some limitation.
Sure there are several ways out. Emacs can do better.
But let's install some recent XEmacs first, otherwise we are
in danger of wasting our time.
,----
|
| The problem is you may not want to do that, if you have a lot of files
| that use the 1/2 character of ISO 8859/1 and only a few in French
| requiring œ.
|
| Check the values of the variable
|
| latin-unity-preapproved-coding-system-list
|
| and take note of the warnings in its docstring:
|
| "*List of coding systems used without querying the user if feasible.
|
| The first feasible coding system in this list is used. The special values
| 'preferred and 'buffer-default may be present:
|
| buffer-default Use the coding system used by `write-region', if feasible.
| preferred Use the coding system specified by `prefer-coding-system'
| if feasible.
|
| \"Feasible\" means that all characters in the buffer can be represented by
| the coding system. Coding systems in `latin-unity-ucs-list' are always
| considered feasible. Other feasible coding systems are computed by
| `latin-unity-representations-feasible-region'.
|
| Most users will want at least one ISO 8859 coding system in this list, as
| otherwise pure ASCII files will not be preapproved. (This is a bug, due
| to the limitation of applicability of this package to Latin and universal.
| The condition that an ISO 8859 coding system be included will be satisfied
| implicitly by 'buffer-default or 'preferred for most users, but it can be
| annoying for users of ISO 2022 or EUC coding systems.)
|
| Note that the first universal coding system in this list shadows all other
| coding systems. In particular, if your preferred coding system is a universal
| coding system, and 'preferred is a member of this list, latin-unity will
| blithely convert all your files to that coding system. This is considered a
| feature, but it may surprise most users. Users who don't like this behavior
| should move 'preferred to `latin-unity-preferred-coding-system-list'."
|
| HTH
|
| Steve
`----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta