3:25 p.m.
Hello
Sorry to repeat the question.
I finished a modified leim-list.el which contains the new hebrew input
method.
However I am unsure about the coding. Should I save the new leim-list.el
in iso-2022 or utf8. I am asking because I have to provide a patch and
do not want to screw up the encoding with the patch.
The original coding is described as
Coding system for saving this buffer:
CText -- ctext-unix
is this correct?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:31 a.m.
Uwe Brauer writes:
Coding system for saving this buffer:
CText -- ctext-unix
No. Don't use CText, that's an old X standard. Also, iso-2022-7bit
is incorrect for XEmacs (I forgot about that). The right one is
iso-2022-jp (despite its name, it is a universal encoding capable of
handling all characters XEmacs has predefined charsets for).
leim-list.el *is* relevant to 21.4, so you *must* use iso-2022-jp (the
current standard universal encoding for packages).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:51 p.m.
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> Coding system for saving this buffer:
> CText -- ctext-unix
No. Don't use CText, that's an old X standard. Also,
iso-2022-7bit
is incorrect for XEmacs (I forgot about that). The right one is
iso-2022-jp (despite its name, it is a universal encoding capable of
handling all characters XEmacs has predefined charsets for).
Oops, I opened read-only leim-list.el either with 21.4.22 Mule or 21.5.33 (using
-vanilla)
and in both cases the coding was detected as
,----
| `file-coding-system' is an alias for `buffer-file-coding-system',a built-in
buffer-local variable.
|
| Value: #<coding_system iso-2022-7bit-unix>
|
| This value is specific to the current buffer.
|
| Default-value: iso-2022-8
|
| Documentation:
| Obsolete; use `buffer-file-coding-system' instead.
`----
So I will copy this file save it as iso-2022-jp
add the string
;;; leim-list.el -- list of LEIM (Library of Emacs Input Method) -*-coding:
iso-2022-jp;-*-
modify it and save it again in this format.
Ooh this seems not to work, I changed
set-buffer-file-coding-system to iso-2022-jp
saved the file but I obtain again
,----
| `buffer-file-coding-system' is a built-in buffer-local variable.
| -- loaded from
"/home/oub/ALLES/Add-Import/xemacs-21.5.33-xsymbol/src/buffer.c"
|
| Value: #<coding-system iso-2022-7bit-unix iso2022(g0=ascii, g1=nil,
| g2=nil, g3=nil, short, seven) eol-type=lf>
|
| This value is specific to the current buffer.
|
| Default-value: utf-8
`----
This odd, BTW be it as it be when I open the file, I do not see all
symbols for example in Chinese-CNS I see some *boxes*.
I think we should settle this before I proceed and srew up the
encoding. I repeat it seems that 21.5.33 does not distinguish between
iso-2022-7bit-unix and iso-2022-jp?
Uwe
leim-list.el *is* relevant to 21.4, so you *must* use iso-2022-jp
(the
current standard universal encoding for packages).
Yes I will also resubmit hebrew.el with iso-2022-jp coding once I know
how to do it. :-D
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:02 p.m.
Ar an naoú lá is fiche de mí na Samhain, scríobh Uwe Brauer:
> leim-list.el *is* relevant to 21.4, so you *must* use
iso-2022-jp (the
> current standard universal encoding for packages).
Yes I will also resubmit hebrew.el with iso-2022-jp coding once I know
how to do it. :-D
Please do *not* send your hebrew.el with iso-2022-jp encoding *if it includes
niqqud.* If it includes niqqud, they will be encoded using ISO-IR-196 escapes
(if you’ve saved the file using XEmacs) or some private GNU Emacs character
set (if you’ve saved the file using GNU Emacs).
Neither of those is understood by XEmacs 21.4, so from the perspective of
that version, the file will be corrupt.
The only advantage of iso-2022-jp over UTF-8 for this context is that
bitbucket won’t display the file as iso-2022-jp, and that is not actually an
advantage.
See ipa-21.5.el, especially the bit at the start of the file that gives up
if XEmacs doesn’t have sufficient support for Unicode, and see also how it’s
handled in the Makefile for the leim package, where it is specified as one
of the EXTRA_SOURCES, not to be compiled. Links here:
https://bitbucket.org/xemacs/leim/src/7286509/quail/ipa-21.5.el?at=default
https://bitbucket.org/xemacs/leim/src/7286509/Makefile?at=default
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:02 p.m.
New subject: iso-2022-7bit vs iso-2022-jp (was: patch against leim-list.el coding)
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> Coding system for saving this buffer:
> CText -- ctext-unix
leim-list.el *is* relevant to 21.4, so you *must* use iso-2022-jp
(the
current standard universal encoding for packages).
I resolved the problem with the coding setting. Once I set the coding
buffer-file-coding-system
return the coding system I have chosen
However I saved leim-list.el as iso-2022-jp and as iso-2022-7bit
and run cksum on both files. They are identical!
So what shall I do?
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:20 a.m.
New subject: iso-2022-7bit vs iso-2022-jp (was: patch against leim-list.el coding)
Uwe Brauer writes:
However I saved leim-list.el as iso-2022-jp and as iso-2022-7bit
and run cksum on both files. They are identical!
That's not surprising to me (as someone somewhat expert in encodings).
The basic encoding schemes are the same. However, iso-2022-7bit is
*much* more lenient when reading files, and what it does when writing
is neither documented as far as I know (except in the source), nor is
it consistent across implementations (eg, we know that XEmacs doesn't
like the GNU Emacs version of iso-2022-7bit -- that's an XEmacs bug, I
believe, but it does show that they are different).
So what shall I do?
Use iso-2022-jp.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4009
days inactive
4012
days old
5 comments
3 participants
participants (3)
-
Aidan Kehoe -
Stephen J. Turnbull -
Uwe Brauer