From: Oliver Scholz <alkibiades@gmx.de>
Cc: storm@cua.dk, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
handa@m17n.org, Oliver Scholz <alkibiades@gmx.de>
Subject: Re: [PATCH] Unicode Lisp reader escapes
Date: Wed, 17 May 2006 14:37:02 +0200 [thread overview]
Message-ID: <87iro4hlox.fsf@gmx.de> (raw)
In-Reply-To: <E1FgCyb-0001Uq-Pk@fencepost.gnu.org> (Richard Stallman's message of "Tue, 16 May 2006 23:45:33 -0400")
Growing a bit tired of this discussion, I hacked a kludge that might
do what you want. It introduces a variable
`byte-compile-no-char-translation' that is meant to be put into the
Local Variables section of an Emacs Lisp source file in order to
inhibit the effects of `utf-fragment-on-decoding' and
`unifiy-8859-on-decoding'. In other words: This patch deals only with
the issues that *I* can understand. I seem to recall that Handa also
mentioned some effects of certain CJK language environments.
It is *absolutely vital*, that Kenichi Handa reviews this patch. I am
not entirely sure whether this breaks something or not.
With my patch, in decode_coding_iso2022 looking up characters in
Vstandard_translation_table_for_decode is inhibited at all if
`byte-compile-no-char-translation' is non-nil. This might be wrong.
Vstandard_translation_table_for_decode is not empty by default. I
guess instead of inhibiting its use one could just temporarily set its
parent at about the same place. But maybe this is unnecessary.
decode_coding_sjis_big5 refers to
Vstandard_translation_table_for_decode, too. I did not modify it,
though, thus introducing a possible inconsistency. The reason is that
I don't understand CJK issues and I don't understand this encoding.
Note: Even with the remaining issues wielded out, IMNSHO this patch is
worse than the two other solutions (1) Tell users to use emacs-mule.
Or: (2) Remove `unify-8859-on-decoding-mode' and
`utf-fragment-on-decoding'. The reasoning goes as follows:
Check: Are `unify-8859-on-decoding-mode' and
`utf-fragment-on-decoding' useful options?
If no: Remove them, since they cause only trouble.
If yes: then a user who set them, will want them for all affected
characters. The choice for unification/fragmention should
not be the choice of the programmer of the Lisp package;
it should be the choice of the user.
(To quote a future user, complaining on gnu-emacs-help:
"The heck! Why do I have only hollow boxes for my Greek
characters after byte compilation??? It's all fine in the
source file!!!")
Exception: In the event that the particular choice of charsets is
important for a Lisp Package: Use `emacs-mule'!
Oliver
Index: lisp/files.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
retrieving revision 1.836
diff -u -r1.836 files.el
--- lisp/files.el 16 May 2006 18:33:31 -0000 1.836
+++ lisp/files.el 17 May 2006 12:08:43 -0000
@@ -2361,6 +2361,7 @@
(left-margin . integerp) ;; C source code
(no-update-autoloads . booleanp)
(tab-width . integerp) ;; C source code
+ (byte-compile-no-char-translation . booleanp) ;; C source code
(truncate-lines . booleanp))) ;; C source code
(put 'c-set-style 'safe-local-eval-function t)
Index: lisp/emacs-lisp/bytecomp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/bytecomp.el,v
retrieving revision 2.185
diff -u -r2.185 bytecomp.el
--- lisp/emacs-lisp/bytecomp.el 16 May 2006 10:05:09 -0000 2.185
+++ lisp/emacs-lisp/bytecomp.el 17 May 2006 12:08:45 -0000
@@ -1673,6 +1673,14 @@
(enable-local-eval nil))
;; Arg of t means don't alter enable-local-variables.
(normal-mode t)
+
+ ;; KLUDGE: `byte-compile-no-char-translation' should affect
+ ;; how characters are decoded. But at this point decoding
+ ;; already happend. So we insert the file contents again.
+ (when byte-compile-no-char-translation
+ (erase-buffer)
+ (insert-file-contents filename))
+
(setq filename buffer-file-name))
;; Set the default directory, in case an eval-when-compile uses it.
(setq default-directory (file-name-directory filename)))
Index: src/coding.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/coding.c,v
retrieving revision 1.336
diff -u -r1.336 coding.c
--- src/coding.c 8 May 2006 05:25:02 -0000 1.336
+++ src/coding.c 17 May 2006 12:08:50 -0000
@@ -405,6 +405,15 @@
Lisp_Object Qcoding_system_p, Qcoding_system_error;
+/* This variable is meant to turn off character tranlation during byte
+ compilation. */
+
+Lisp_Object Vbyte_compile_no_char_translation;
+
+Lisp_Object empty_translation_table;
+Lisp_Object Qucs_translation_table_for_decode, Qutf_translation_table_for_decode;
+Lisp_Object Qunify_8859_on_decoding_mode, Qutf_fragment_on_decoding;
+
/* Coding system emacs-mule and raw-text are for converting only
end-of-line format. */
Lisp_Object Qemacs_mule, Qraw_text;
@@ -1849,7 +1858,7 @@
else
{
translation_table = coding->translation_table_for_decode;
- if (NILP (translation_table))
+ if (NILP (translation_table) && NILP (Vbyte_compile_no_char_translation))
translation_table = Vstandard_translation_table_for_decode;
}
@@ -4938,8 +4947,48 @@
dst_bytes--;
extra = coding->spec.ccl.cr_carryover;
}
- ccl_coding_driver (coding, source, destination + extra,
- src_bytes, dst_bytes, 0);
+
+ /*KLUDGE: Inhibit unification and or fragmentation. This is
+ meant for byte compiling Emacs Lisp source files. For CCL
+ based coding systems it has to be done here, because we want
+ it only for decoding. We temporarily swap the affected
+ translation tables in Vtranslation_table_vector with an empty
+ translation table.*/
+ if (! NILP (Vbyte_compile_no_char_translation)
+ && (! NILP (SYMBOL_VALUE (Qunify_8859_on_decoding_mode))
+ || ! NILP (SYMBOL_VALUE (Qutf_fragment_on_decoding))))
+ {
+ if (NILP (empty_translation_table))
+ {
+ empty_translation_table =
+ call0 (intern ("make-translation-table"));
+ }
+
+ Lisp_Object ucs_tt = Fget (Qucs_translation_table_for_decode, Qtranslation_table);
+ Lisp_Object ucs_id = Fget (Qucs_translation_table_for_decode, Qtranslation_table_id);
+
+ Lisp_Object utf_tt = Fget (Qutf_translation_table_for_decode, Qtranslation_table);
+ Lisp_Object utf_id = Fget (Qutf_translation_table_for_decode, Qtranslation_table_id);
+
+ /* Should this be `unwind-protect'ed? */
+
+ Faset (Vtranslation_table_vector, ucs_id, Fcons (Qucs_translation_table_for_decode,
+ empty_translation_table));
+ Faset (Vtranslation_table_vector, utf_id, Fcons (Qutf_translation_table_for_decode,
+ empty_translation_table));
+
+ ccl_coding_driver (coding, source, destination + extra,
+ src_bytes, dst_bytes, 0);
+
+ Faset (Vtranslation_table_vector, ucs_id, Fcons (Qucs_translation_table_for_decode,
+ ucs_tt));
+ Faset (Vtranslation_table_vector, utf_id, Fcons (Qutf_translation_table_for_decode,
+ utf_tt));
+
+ }
+ else ccl_coding_driver (coding, source, destination + extra,
+ src_bytes, dst_bytes, 0);
+
if (coding->eol_type != CODING_EOL_LF)
{
coding->produced += extra;
@@ -7852,6 +7901,34 @@
defsubr (&Sset_coding_priority_internal);
defsubr (&Sdefine_coding_system_internal);
+ DEFVAR_LISP ("byte-compile-no-char-translation", &Vbyte_compile_no_char_translation,
+ doc: /* Don't translate characters during byte compilation.
+
+Options like `utf-fragment-on-decoding' or the minor mode
+`unify-8859-on-decoding-mode' modify the way Emacs maps file encodings
+to mule charsets. Since *.elc files are encoded in emacs-mule, such
+settings are preserved in the compiled file. If this variable is
+non-nil, Emacs uses the default mule charsets.
+
+You can set this variable in the local variables section of a file. */);
+ Vbyte_compile_no_char_translation = Qnil;
+
+ empty_translation_table = Qnil;
+ staticpro (&empty_translation_table);
+
+ Qucs_translation_table_for_decode = intern ("ucs-translation-table-for-decode");
+ staticpro (&Qucs_translation_table_for_decode);
+
+ Qutf_translation_table_for_decode = intern ("utf-translation-table-for-decode");
+ staticpro (&Qutf_translation_table_for_decode);
+
+ Qunify_8859_on_decoding_mode = intern ("unify-8859-on-decoding-mode");
+ staticpro (&Qunify_8859_on_decoding_mode);
+
+ Qutf_fragment_on_decoding = intern ("utf-fragment-on-decoding");
+ staticpro (&Qunify_8859_on_decoding_mode);
+
+
DEFVAR_LISP ("coding-system-list", &Vcoding_system_list,
doc: /* List of coding systems.
--
Oliver Scholz 28 Floréal an 214 de la Révolution
Ostendstr. 61 Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.
next prev parent reply other threads:[~2006-05-17 12:37 UTC|newest]
Thread overview: 202+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-29 15:35 [PATCH] Unicode Lisp reader escapes Aidan Kehoe
2006-04-29 23:26 ` Stefan Monnier
2006-04-30 8:26 ` Aidan Kehoe
2006-04-30 3:04 ` Richard Stallman
2006-04-30 8:14 ` Aidan Kehoe
2006-04-30 20:53 ` Richard Stallman
2006-04-30 21:04 ` Andreas Schwab
2006-04-30 21:57 ` Aidan Kehoe
2006-04-30 22:14 ` Andreas Schwab
2006-05-01 18:32 ` Richard Stallman
2006-05-01 19:03 ` Oliver Scholz
2006-05-02 4:45 ` Richard Stallman
2006-05-02 0:46 ` Kenichi Handa
2006-05-02 6:41 ` Aidan Kehoe
2006-05-02 21:36 ` Richard Stallman
2006-04-30 21:56 ` Aidan Kehoe
2006-05-01 1:44 ` Miles Bader
2006-05-01 3:12 ` Stefan Monnier
2006-05-01 3:41 ` Miles Bader
2006-05-01 12:29 ` Stefan Monnier
2006-05-05 23:15 ` Juri Linkov
2006-05-06 23:36 ` Richard Stallman
2006-05-09 20:43 ` Juri Linkov
2006-05-11 3:44 ` Richard Stallman
2006-05-11 12:03 ` Juri Linkov
2006-05-11 13:16 ` Kenichi Handa
2006-05-12 4:15 ` Richard Stallman
2006-06-03 18:44 ` Aidan Kehoe
[not found] ` <17537.54719.354843.89030@parhasard.net>
[not found] ` <ufyieqj0v.fsf@gnu.org>
2006-06-15 18:38 ` Aidan Kehoe
2006-06-17 18:57 ` Eli Zaretskii
2006-06-18 16:11 ` Aidan Kehoe
2006-06-18 19:55 ` Eli Zaretskii
2006-06-20 2:37 ` Kenichi Handa
2006-06-20 17:56 ` Richard Stallman
2006-06-23 18:35 ` Aidan Kehoe
2006-06-24 6:50 ` Eli Zaretskii
2006-05-02 6:43 ` Kenichi Handa
2006-05-02 7:00 ` Aidan Kehoe
2006-05-02 10:45 ` Eli Zaretskii
2006-05-02 11:13 ` Aidan Kehoe
2006-05-02 19:31 ` Eli Zaretskii
2006-05-02 20:25 ` Aidan Kehoe
2006-05-02 22:16 ` Oliver Scholz
2006-05-02 11:33 ` Kenichi Handa
2006-05-02 22:50 ` Aidan Kehoe
2006-05-03 7:43 ` Kenichi Handa
2006-05-03 17:21 ` Kevin Rodgers
2006-05-03 18:51 ` Andreas Schwab
2006-05-04 21:14 ` Aidan Kehoe
2006-05-08 1:31 ` Kenichi Handa
2006-05-08 6:54 ` Aidan Kehoe
2006-05-08 13:55 ` Stefan Monnier
2006-05-08 14:24 ` Aidan Kehoe
2006-05-08 15:32 ` Stefan Monnier
2006-05-08 16:39 ` Aidan Kehoe
2006-05-08 17:39 ` Stefan Monnier
2006-05-09 7:04 ` Aidan Kehoe
2006-05-09 19:05 ` Eli Zaretskii
2006-05-10 6:05 ` Aidan Kehoe
2006-05-10 17:49 ` Eli Zaretskii
2006-05-10 21:37 ` Luc Teirlinck
2006-05-11 3:45 ` Eli Zaretskii
2006-05-10 21:48 ` Luc Teirlinck
2006-05-11 1:08 ` Luc Teirlinck
2006-05-11 2:29 ` Luc Teirlinck
2006-05-11 3:46 ` Richard Stallman
2006-05-09 0:36 ` Kenichi Handa
2006-05-02 10:36 ` Eli Zaretskii
2006-05-02 10:59 ` Aidan Kehoe
2006-05-02 19:26 ` Eli Zaretskii
2006-05-03 2:59 ` Kenichi Handa
2006-05-03 8:47 ` Eli Zaretskii
2006-05-03 14:21 ` Stefan Monnier
2006-05-03 18:26 ` Eli Zaretskii
2006-05-03 21:12 ` Ken Raeburn
2006-05-04 14:17 ` Richard Stallman
2006-05-04 16:41 ` Aidan Kehoe
2006-05-05 10:39 ` Eli Zaretskii
2006-05-05 16:35 ` Aidan Kehoe
2006-05-05 19:05 ` Richard Stallman
2006-05-05 19:20 ` Aidan Kehoe
2006-05-05 19:57 ` Aidan Kehoe
2006-05-06 14:25 ` Richard Stallman
2006-05-06 17:26 ` Aidan Kehoe
2006-05-07 5:01 ` Richard Stallman
2006-05-07 6:38 ` Aidan Kehoe
2006-05-07 7:00 ` David Kastrup
2006-05-07 7:15 ` Aidan Kehoe
2006-05-07 16:50 ` Aidan Kehoe
2006-05-08 22:28 ` Richard Stallman
2006-05-04 1:33 ` Kenichi Handa
2006-05-04 8:23 ` Oliver Scholz
2006-05-04 11:57 ` Kim F. Storm
2006-05-04 12:18 ` Stefan Monnier
2006-05-04 12:21 ` Kim F. Storm
2006-05-04 16:31 ` Eli Zaretskii
2006-05-04 21:40 ` Stefan Monnier
2006-05-05 10:25 ` Eli Zaretskii
2006-05-05 12:31 ` Oliver Scholz
2006-05-05 18:08 ` Stuart D. Herring
2006-05-05 13:05 ` Stefan Monnier
2006-05-05 17:23 ` Oliver Scholz
2006-05-04 13:07 ` Oliver Scholz
2006-05-04 16:32 ` Eli Zaretskii
2006-05-04 20:55 ` Aidan Kehoe
2006-05-05 9:33 ` Oliver Scholz
2006-05-05 10:02 ` Oliver Scholz
2006-05-05 18:33 ` Aidan Kehoe
2006-05-05 18:42 ` Oliver Scholz
2006-05-05 21:37 ` Eli Zaretskii
2006-05-06 14:24 ` Richard Stallman
2006-05-06 15:01 ` Oliver Scholz
[not found] ` <877j4z5had.fsf@gmx.de>
2006-05-07 5:00 ` Richard Stallman
2006-05-07 12:38 ` Kenichi Handa
2006-05-07 21:26 ` Oliver Scholz
2006-05-08 1:14 ` Kenichi Handa
2006-05-08 22:29 ` Richard Stallman
2006-05-09 3:42 ` Eli Zaretskii
2006-05-09 20:41 ` Richard Stallman
2006-05-09 21:03 ` Stefan Monnier
2006-05-10 3:33 ` Eli Zaretskii
2006-05-09 5:13 ` Kenichi Handa
2006-05-10 3:20 ` Richard Stallman
2006-05-10 5:37 ` Kenichi Handa
2006-05-10 7:22 ` Stefan Monnier
2006-05-11 3:45 ` Richard Stallman
2006-05-11 12:41 ` Stefan Monnier
2006-05-11 12:51 ` Kenichi Handa
2006-05-11 16:46 ` Stefan Monnier
2006-05-11 3:44 ` Richard Stallman
2006-05-11 3:44 ` Richard Stallman
2006-05-11 7:31 ` Kenichi Handa
2006-05-12 4:14 ` Richard Stallman
2006-05-12 5:26 ` Kenichi Handa
2006-05-13 4:52 ` Richard Stallman
2006-05-13 13:25 ` Stefan Monnier
2006-05-13 20:41 ` Richard Stallman
2006-05-14 13:32 ` Stefan Monnier
2006-05-14 23:29 ` Richard Stallman
2006-05-15 0:55 ` Stefan Monnier
2006-05-15 2:49 ` Oliver Scholz
2006-05-15 3:27 ` Stefan Monnier
2006-05-15 10:20 ` Oliver Scholz
2006-05-15 11:12 ` Oliver Scholz
2006-05-15 20:37 ` Richard Stallman
2006-05-16 9:49 ` Oliver Scholz
2006-05-16 11:16 ` Kim F. Storm
2006-05-16 11:39 ` Romain Francoise
2006-05-16 11:58 ` Oliver Scholz
2006-05-16 14:24 ` Kim F. Storm
2006-05-17 3:45 ` Richard Stallman
2006-05-17 8:37 ` Oliver Scholz
2006-05-17 20:09 ` Richard Stallman
2006-05-17 12:37 ` Oliver Scholz [this message]
2006-05-19 2:05 ` Richard Stallman
2006-05-19 8:47 ` Oliver Scholz
2006-05-18 1:09 ` Kenichi Handa
2006-05-21 0:57 ` Richard Stallman
2006-05-22 1:33 ` Kenichi Handa
2006-05-22 15:12 ` Richard Stallman
2006-05-23 1:05 ` Kenichi Handa
2006-05-23 5:18 ` Juri Linkov
2006-05-24 2:18 ` Richard Stallman
2006-06-02 6:49 ` Kenichi Handa
2006-06-02 8:00 ` Kim F. Storm
2006-06-02 9:27 ` Juri Linkov
2006-06-02 10:50 ` Eli Zaretskii
2006-06-02 11:39 ` Kenichi Handa
2006-06-02 12:12 ` Juri Linkov
2006-06-02 22:39 ` Richard Stallman
2006-06-03 6:42 ` Juri Linkov
2006-06-04 2:23 ` Richard Stallman
2006-06-05 7:24 ` Kenichi Handa
2006-06-05 21:31 ` Richard Stallman
2006-06-07 1:24 ` Kenichi Handa
2006-06-02 22:39 ` Richard Stallman
2006-05-24 2:17 ` Richard Stallman
2006-05-17 15:15 ` Stefan Monnier
2006-05-17 3:45 ` Richard Stallman
2006-05-17 3:45 ` Richard Stallman
2006-05-17 8:53 ` Oliver Scholz
2006-05-17 20:09 ` Richard Stallman
2006-05-18 9:12 ` Oliver Scholz
2006-05-15 20:37 ` Richard Stallman
2006-05-15 5:13 ` Kenichi Handa
2006-05-15 8:06 ` Kim F. Storm
2006-05-15 9:04 ` Andreas Schwab
2006-05-15 20:38 ` Richard Stallman
2006-05-15 14:08 ` Stefan Monnier
2006-05-15 20:37 ` Richard Stallman
2006-05-16 10:07 ` Oliver Scholz
2006-05-18 0:31 ` Kenichi Handa
2006-05-11 9:44 ` Oliver Scholz
2006-05-08 7:36 ` Richard Stallman
2006-05-08 7:50 ` Kenichi Handa
2006-05-05 19:05 ` Richard Stallman
2006-05-05 21:43 ` Eli Zaretskii
2006-05-06 14:25 ` Richard Stallman
2006-05-04 1:26 ` Kenichi Handa
[not found] <E1FaJ0b-0008G8-8u@monty-python.gnu.org>
2006-04-30 21:16 ` Jonathan Yavner
2006-05-01 18:32 ` Richard Stallman
2006-05-02 5:03 ` Jonathan Yavner
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=87iro4hlox.fsf@gmx.de \
--to=alkibiades@gmx.de \
--cc=emacs-devel@gnu.org \
--cc=handa@m17n.org \
--cc=monnier@iro.umontreal.ca \
--cc=storm@cua.dk \
/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).