From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Re: Inadequate documentation of silly characters on screen. Date: Fri, 20 Nov 2009 12:13:51 +0900 Message-ID: <87ws1l7us0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20091118191258.GA2676@muc.de> <20091119082040.GA1720@muc.de> <874ooq8xay.fsf@wanchan.jasonrumney.net> <20091119141852.GC1720@muc.de> <20091119155848.GB1314@muc.de> <19205.30349.786007.611623@parhasard.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1258686461 468 80.91.229.12 (20 Nov 2009 03:07:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2009 03:07:41 +0000 (UTC) Cc: Aidan Kehoe , Alan Mackenzie , emacs-devel@gnu.org, Andreas Schwab , Jason Rumney To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 04:07:33 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NBJqP-0004dQ-GX for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2009 04:07:33 +0100 Original-Received: from localhost ([127.0.0.1]:51542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBJqP-0006bH-4V for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2009 22:07:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBJqG-0006XR-Iz for emacs-devel@gnu.org; Thu, 19 Nov 2009 22:07:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBJqC-0006Uo-P4 for emacs-devel@gnu.org; Thu, 19 Nov 2009 22:07:24 -0500 Original-Received: from [199.232.76.173] (port=40315 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBJqC-0006Uh-HK for emacs-devel@gnu.org; Thu, 19 Nov 2009 22:07:20 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45307) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBJq9-0000qh-Q6; Thu, 19 Nov 2009 22:07:18 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1523F820E; Fri, 20 Nov 2009 12:07:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BF65B1A25EE; Fri, 20 Nov 2009 12:13:53 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:117318 Archived-At: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: > Indeed XEmacs does not represent chars as integers, and that can > eliminate several sources of problems. Note that this problem is new in > Emacs-23, since in Emacs-22 (and in XEmacs, IIUC), there was no > character whose integer value was between 127 and 256, so there was no > ambiguity. In XEmacs: (char-int-p 241) =3D> t (int-char 241) =3D> ?=F1 No problems with this that I can recall, except a few people with code that did (set-face-font 'default "-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2") --=-=-= Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable and expected `(insert (int-char 241))' to display `=F1' instead of=20 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable `=F1'. (For the non-Mule-implementers, this hack works without Mule but won't work in Mule because Mule matches those two trailing fields to the character's charset, and 241 corresponds to a Latin-1 character, so a "-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1" font from the set associated with the default face will be used.) For this reason, using char-int and int-char in XEmacs is generally a bug unless you want to examine the internal coding system; you almost always want to use make-char. (Of course for ASCII values it's an accepted idiom, but still a bad habit.) > AFAIK most of the programming errors we've had to deal with over the > years (i.e. in Emacs-20, 21, 22) had to do with incorrect (or missing) > encoding/decoding and most of those errors existed just as much on > XEmacs I don't think that's true; AFAIK we have *no* recorded instances of the \201 bug, while that regression persisted in GNU Emacs (albeit a patched version, at first) from at the latest 1992 until just a few years ago. I think it got fixed in Mule (ie, all paths into or out of a text object got a coding stage) before that was integrated into XEmacs or Emacs, and the regression when Mule was integrated into Emacs was cause by the performance hack, "text object as unibyte". > because there's no way to fix them right in the infrastructure code > (tho XEmacs may have managed to hide them better by detecting the > lack of encoding/decoding and guessing an appropriate coding-system > instead). I don't know of any such guessing. When the user asks us to, we guess on input, just as you do, but once we've got text in internal format, there is no more guessing to be done. Emacs will encounter the need to guess because you support "text object as unibyte". Vive la difference technical! ;-) --=-=-=--