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: Inadequate documentation of silly characters on screen. Date: Sat, 21 Nov 2009 13:13:36 +0900 Message-ID: <87hbso347j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20091118191258.GA2676@muc.de> <20091119082040.GA1720@muc.de> <87aayitvoy.fsf@wanchan.jasonrumney.net> <87ocmyf6so.fsf@catnip.gol.com> <87vdh57tp2.fsf@uwakimon.sk.tsukuba.ac.jp> <878we1ekb0.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258776459 30924 80.91.229.12 (21 Nov 2009 04:07:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2009 04:07:39 +0000 (UTC) Cc: Alan Mackenzie , Jason Rumney , emacs-devel@gnu.org, Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 05:07:32 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 1NBhFu-0002LV-AU for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 05:07:26 +0100 Original-Received: from localhost ([127.0.0.1]:34028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBhFt-00039n-Dz for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2009 23:07:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBhFp-00039a-5f for emacs-devel@gnu.org; Fri, 20 Nov 2009 23:07:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBhFk-000398-Cw for emacs-devel@gnu.org; Fri, 20 Nov 2009 23:07:20 -0500 Original-Received: from [199.232.76.173] (port=38913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBhFk-000395-AH for emacs-devel@gnu.org; Fri, 20 Nov 2009 23:07:16 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:44679) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBhFe-0007jP-Oj; Fri, 20 Nov 2009 23:07:11 -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 504A8820F; Sat, 21 Nov 2009 13:07:07 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DA72F1A25EE; Sat, 21 Nov 2009 13:13:36 +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:117400 Archived-At: Stefan Monnier writes: > string-as-unibyte returns a new string, so no: they were not the same. Sorry, `toggle-enable-multibyte-characters' was what I had in mind. So, yes, they *were* *indeed* the same. YHBT (it wasn't intentional). I dunno, de gustibus non est disputandum and all that, but this idea of having an in-band representation for raw bytes in a multibyte string sounds to me like more trouble than it's worth. I think it would be much better to serve (eg) AUCTeX's needs with a special coding system that grabs some unlikely-to-be-used private code space and puts the bytes there. That puts the responsibility for dealing with such perversity[1] on the people who have some idea what they're dealing with, not unsuspecting CC Mode maintainers who won't be using that coding system. And it should be either an error to (aset string pos 241) (sorry Alan!) or 241 should be implicitly interpreted as Latin-1 (ie, ?=F1). I favor the former, because what Alan is doing screws Spanish-speaking users AFAICS. OTOH, the latter extends naturally if you have plans to add support for fixed-width Unicode buffers (UTF-16 and UTF-32). Vive la diff=E9rence techniquement! Footnotes:=20 [1] In the sense of "the world is perverse", I'm not blaming AUCTeX or TeX for this!