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: Thu, 11 May 2006 11:44:58 +0200 Message-ID: <87k68s99ph.fsf@gmx.de> References: <17491.34779.959316.484740@parhasard.net> <87odyfnqcj.fsf-monnier+emacs@gnu.org> <17498.27200.911709.330947@parhasard.net> <877j4z5had.fsf@gmx.de> <87irohfrx1.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 1147340790 8127 80.91.229.2 (11 May 2006 09:46:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 May 2006 09:46:30 +0000 (UTC) Cc: alkibiades@gmx.de, emacs-devel@gnu.org, Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 11 11:46:28 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 1Fe7kZ-0003Rl-6Q for ged-emacs-devel@m.gmane.org; Thu, 11 May 2006 11:46:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fe7kY-0007NT-Ga for ged-emacs-devel@m.gmane.org; Thu, 11 May 2006 05:46:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fe7kK-0007N1-9K for emacs-devel@gnu.org; Thu, 11 May 2006 05:46:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fe7kI-0007LL-Ud for emacs-devel@gnu.org; Thu, 11 May 2006 05:46:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fe7kI-0007LD-MJ for emacs-devel@gnu.org; Thu, 11 May 2006 05:46:10 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1Fe7lm-0002bL-9I for emacs-devel@gnu.org; Thu, 11 May 2006 05:47:42 -0400 Original-Received: (qmail invoked by alias); 11 May 2006 09:46:08 -0000 Original-Received: from dslb-084-058-134-092.pools.arcor-ip.net (EHLO localhost.localdomain.gmx.de) [84.58.134.92] by mail.gmx.net (mp038) with SMTP; 11 May 2006 11:46:08 +0200 X-Authenticated: #1497658 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Wed, 10 May 2006 23:44:55 -0400") 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:54252 Archived-At: Richard Stallman writes: > > Add a new "variable" `buffer-coding' which is analogous to `coding'. > > Whereas `coding' specifies the encoding in the file, `buffer-coding' > > specifies the in-buffer encoding to produce in the buffer. Its val= ue > > could be a list or plist, which would specify the values of all the= se > > many variables. > > > What do you think? If you think this is a good idea, could > > you try designing the details? > > No, it's an incredibly hard and heavy task. > > I am surprised you think so, and this means there is some sort of > misunderstanding between us. > > You've listed around 6 variables that affect the decoding. So it > seems to me that if we make a convenient way for each Lisp file to > specify those 6 variables, we solve the problem. It looks easy to me. Yes, I think there is a misunderstanding. It is not the value of those variables that affects decoding. But changing the value of those variables via their corresponding minor mode functions or via customize initialises translation tables (char tables and arrays) and in some cases adjusts codings systems to use those tables. See `ucs-unify-8859' and its counterpart `ucs-fragment-8859' for an example. In most, if not all affected cases, binding variables to another value would have no effect whatsoever. In some cases like `utf-fragment-on-decoding' you'd first have to write functions to programmatically cause the associated effect. In fact, it might be easier (and even safer) to just change the encoding of *.elc files from emacs-mule to utf-8. Then there may be possible consecutive problems. For instance, Handa-san mentioned an example of how a user could have reason to modify the affected translation tables. Are users supposed to do that? (I'd argue, they should rather change the fontset.) If yes, you'd need to make sure that such changes are preserved after swapping and/or redefining all those translation tables during byte compilation. Maybe they are anyways, but we are talking about a lot of mule code here. Finally, users might encounter *either* behaviour in a way that makes them think it is a bug. If byte compilation is modified the way you propose, then what some users will probably just see is that the glyphs of some characters coming from a byte compiled file differ from what they specified in their .emacs. That will come as a surprise to them and investigating it is not exactly easy, if you are not familiar with Emacs' internal handling of characters. So it might be a good idea to document even the fix of the bug we are discussing in etc/PROBLEMS, because it *is* a design problem of `emacs-mule'. (And as Handa-san mentioned, things like that are the actual reason that changing the internal encoding to UTF-8 is a worthwile enterprise in the first place.) Oliver --=20 Oliver Scholz 22 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