From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Inadequate documentation of silly characters on screen. Date: Sat, 21 Nov 2009 00:24:08 -0500 Message-ID: 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> <87hbso347j.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 1258781073 5976 80.91.229.12 (21 Nov 2009 05:24:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2009 05:24:33 +0000 (UTC) Cc: Alan Mackenzie , Jason Rumney , emacs-devel@gnu.org, Miles Bader To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 06:24:25 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 1NBiSO-0006Y4-W8 for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 06:24:25 +0100 Original-Received: from localhost ([127.0.0.1]:51766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBiSO-00061I-GI for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 00:24:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBiSI-00060n-U6 for emacs-devel@gnu.org; Sat, 21 Nov 2009 00:24:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBiSE-0005xS-6a for emacs-devel@gnu.org; Sat, 21 Nov 2009 00:24:18 -0500 Original-Received: from [199.232.76.173] (port=48675 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBiSE-0005xK-1O for emacs-devel@gnu.org; Sat, 21 Nov 2009 00:24:14 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:62072 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBiS9-0002oS-Op; Sat, 21 Nov 2009 00:24:09 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAAMIB0vO+IIa/2dsb2JhbACBTtNihDwEgxeGZA X-IronPort-AV: E=Sophos;i="4.47,262,1257138000"; d="scan'208";a="49772365" Original-Received: from 206-248-130-26.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.26]) by ironport2-out.pppoe.ca with ESMTP; 21 Nov 2009 00:24:09 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id CC2D780E3; Sat, 21 Nov 2009 00:24:08 -0500 (EST) In-Reply-To: <87hbso347j.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 21 Nov 2009 13:13:36 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:117410 Archived-At: > Sorry, `toggle-enable-multibyte-characters' was what I had in mind. > So, yes, they *were* *indeed* the same. YHBT (it wasn't intentional). Oh, yes, *that* one. I haven't yet managed to run a useful Emacs instance with an "assert (BEG =3D=3D Z);" at the entrance to this nasty function, but I keep hoping I'll get there. > 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. I don't know what you mean. The eight-bit "chars" were introduced to make sure that decoding+reencoding will always return the exact same byte-sequence, no matter what coding-system was used (i.e. even if the byte-sequence is invaldi for that coding-system). Dunno how XEmacs handles it. > 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). I understand this even less. I think XEmacs's fundamental tradeoffs are subtly different but lead to very far-reaching consequences, and for that reason it's difficult for us to take a step back and understand the other point of view. Stefan