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: Mon, 15 May 2006 12:20:05 +0200 Message-ID: <878xp3oai2.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> <87psigou2p.fsf-monnier+emacs@gnu.org> 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 1147688504 15573 80.91.229.2 (15 May 2006 10:21:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 May 2006 10:21:44 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, handa@m17n.org, Oliver Scholz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 15 12:21:40 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 1FfaCh-0007l8-7S for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 12:21:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfaCg-0003XF-DX for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 06:21:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FfaCV-0003XA-6W for emacs-devel@gnu.org; Mon, 15 May 2006 06:21:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FfaCU-0003Wy-Af for emacs-devel@gnu.org; Mon, 15 May 2006 06:21:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfaCU-0003Wv-6j for emacs-devel@gnu.org; Mon, 15 May 2006 06:21:18 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1FfaEs-0000MB-5o for emacs-devel@gnu.org; Mon, 15 May 2006 06:23:46 -0400 Original-Received: (qmail invoked by alias); 15 May 2006 10:21:16 -0000 Original-Received: from dslb-084-058-182-165.pools.arcor-ip.net (EHLO localhost.localdomain.gmx.de) [84.58.182.165] by mail.gmx.net (mp023) with SMTP; 15 May 2006 12:21:16 +0200 X-Authenticated: #1497658 Original-To: Stefan Monnier In-Reply-To: <87psigou2p.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sun, 14 May 2006 23:27:20 -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:54500 Archived-At: Stefan Monnier writes: > I'm not sure I understand the nitpick: [...] That is entirely my mistake. It was late when I wrote the message and my mind was occupied with utf-8 and `utf-fragment-on-decoding'. So I misunderstood you as implying that ucs-table were encoded in UTF-8. > I'm actually not sure if using emacs-mule instead of iso-2022 helps. > It depends on whether or not unify-8859-on-decoding is also applied to > emacs-mule "decoding". It doesn't. decode_coding_emacs_mule in coding.c doesn't refer to Vstandard_translation_table_for_decode at all, which would be necessary for unification. >> Though, the only way to deal with the latter would be to modify the >> Lisp printer for writing *.elc files so that it escapes non-ascii >> characters whereever possible with the new \u syntax. This would be >> another solution to the problem we are discussing.] > > This would break the compilation of ucs-tables.el. Ah, of course, I have not thought about that. Well, there would have to be an exeption. I am not saying that this idea of mine is a good idea, though, because I don't know how hairy it is to implement this. IIRC `encode-char' and `decode-char' are not entirely symmetric, that is, there are characters that `encode-char' can encode, but `decode-char' can't encode. IIRC. But it would be the solution that DTRT from the user's point of view. And it *could* be less hairy than any of the other options discussed here, save "use emacs mule!" and "warn/throw an error/document the problem", of course. Oliver --=20 Oliver Scholz 26 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