From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Unicode Lisp reader escapes Date: Tue, 16 May 2006 11:49:17 +0200 Message-ID: <87u07qcnaa.fsf@gmx.de> References: <17491.34779.959316.484740@parhasard.net> <877j4z5had.fsf@gmx.de> <87irohfrx1.fsf@gmx.de> <87iroarr9i.fsf-monnier+emacs@gnu.org> <87d5egrb4c.fsf-monnier+emacs@gnu.org> <87ves8p0us.fsf-monnier+emacs@gnu.org> <87ves8ngtb.fsf@gmx.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1147773390 23176 80.91.229.2 (16 May 2006 09:56:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 May 2006 09:56:30 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, handa@m17n.org, Oliver Scholz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 16 11:56:27 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FfwHx-0002DR-8j for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 11:56:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfwHw-0004Dr-QU for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 05:56:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FfwHm-0004DZ-PK for emacs-devel@gnu.org; Tue, 16 May 2006 05:56:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FfwHl-0004DL-AL for emacs-devel@gnu.org; Tue, 16 May 2006 05:56:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfwHl-0004DI-7u for emacs-devel@gnu.org; Tue, 16 May 2006 05:56:13 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1FfwKM-0000IC-Ri for emacs-devel@gnu.org; Tue, 16 May 2006 05:58:55 -0400 Original-Received: (qmail invoked by alias); 16 May 2006 09:50:38 -0000 Original-Received: from dslb-084-058-164-137.pools.arcor-ip.net (EHLO localhost.localdomain.gmx.de) [84.58.164.137] by mail.gmx.net (mp038) with SMTP; 16 May 2006 11:50:38 +0200 X-Authenticated: #1497658 Original-To: rms@gnu.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.0 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54565 Archived-At: Richard Stallman writes: > >> Here's one idea: if the -*- line specifies `coding' and specifies > >> the mode `emacs-lisp' then force unify-8859-on-decoding to nil > >> for that file. > > Besides the work already mentioned, this would also require to turn > unify-8859-on-decoding-mode into a buffer-local minor mode. > > That is not the only possible implementation mechanism. The commands > that read and write the buffer could change it temporarily and change > it back. > > However, it seems like a really bad thing to have a minor mode > that CAN'T be buffer-local. Why can't it be? What is the difficulty? Well, as already mentioned, unification and fragmentation are implemented by means of translation tables. Unification, for instance, for non-CCL decodings happens by means of modifying the parent of the char table in the variable `standard-translation-table-for-decode'. This is accessed as Vstandard_translation_table_for_decode in the various decode_coding_XXX functions, for instance decode_coding_iso2022, which affects many of the ISO 8859 coding systems. I have no idea whether it is simple to make this variable buffer local or not. But, well, it's certainly intrusive to change such things at the very heart and core of Emacs' decoding/encoding apparatus. (And I'd like to second Kenichi Handa here: you'd might like to change to Unicode Emacs *now* rather than making this kind of modification. The Emacs Unicode branch is in sync with the current HEAD. Wielding out the remaining coding issues means possibly possibly not much more work and possibly *not* much more destabilizing than some of the modifications we are discussing here.) As for CCL-based coding systems, it is even a bit more difficult. CCL coding systems do the translation table lookup in the CCL program (with the CCL command `translate-character'). A named translation table is *not* stored in a variable; it is stored in a `translation-table' symbol property of the translation table's name. The translation table relevant for unification in CCL decoding is `ucs-translation-table-for-decode' (AFAICS only the cyrillic encodings make use of this). The translation table relevant for fragmentation of UCS coding systems is `utf-translation-table-for-decode'. You'd have to find a way to make *that* buffer local. As for being bad ... no, I don't think that it is bad that those minor modes are global. They are a means to tune some details of Emacs' internal handling of coding systems. *Internal* is the key point here. It is nothing that conceptually relates to a particular file. (This whole issue is something users should IMO not concern themselves with. The benefit of changing the defaults is IMO dubious, anyways. I expect that "unify on decoding of ISO 8859-*" and "fragmentation of UCS" will mostly be abused for dealing with glyph issues -- i.e. something that should be dealt with by adjusting the fontset.) We are discussing a *very* special case here; it affects only Emacs Lisp source files, because compilation of those, so to say, "freezes" the particular settings for unification/fragmentation in the *.elc file. Oliver --=20 Oliver Scholz 27 Flor=C3=A9al an 214 de la R=C3=A9volution Ostendstr. 61 Libert=C3=A9, Egalit=C3=A9, Fraternit=C3=A9! 60314 Frankfurt a. M.=20=20=20=20=20=20=20