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: Sun, 22 Nov 2009 20:58:48 -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> <877htk2xbk.fsf@uwakimon.sk.tsukuba.ac.jp> <874ooo2v7x.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 1258941547 8440 80.91.229.12 (23 Nov 2009 01:59:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 01:59:07 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 02:59:00 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 1NCOCh-00040b-Sy for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 02:59:00 +0100 Original-Received: from localhost ([127.0.0.1]:58163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCOCh-0002rc-7D for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 20:58:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCOCb-0002rF-UC for emacs-devel@gnu.org; Sun, 22 Nov 2009 20:58:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCOCX-0002pE-HJ for emacs-devel@gnu.org; Sun, 22 Nov 2009 20:58:53 -0500 Original-Received: from [199.232.76.173] (port=36564 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCOCX-0002p5-AV for emacs-devel@gnu.org; Sun, 22 Nov 2009 20:58:49 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:56373 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCOCX-0003tJ-0p for emacs-devel@gnu.org; Sun, 22 Nov 2009 20:58:49 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPZ6CUvO+IIa/2dsb2JhbACBTdF8hDwEgxmGaQ X-IronPort-AV: E=Sophos;i="4.47,268,1257138000"; d="scan'208";a="49822326" Original-Received: from 206-248-130-26.dsl.teksavvy.com (HELO ceviche.home) ([206.248.130.26]) by ironport2-out.pppoe.ca with ESMTP; 22 Nov 2009 20:58:48 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 4513AB40C9; Sun, 22 Nov 2009 20:58:48 -0500 (EST) In-Reply-To: <874ooo2v7x.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 21 Nov 2009 16:27:46 +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:117532 Archived-At: > So the problem is that because characters are integers and vice versa, > there's no way for the user to let Emacs duck-type multibyte vs > unibyte strings for him. If he cares, he needs to check. If he > doesn't care, eventually Emacs will punish him for his lapse. > I suppose subst-char-in-string is similarly useless for Alan's > purpose, then? What he really needs to use is something like > (replace-in-string str "\n" "=F1") > right? Pretty much yes. When chars come within strings, the multibyteness of the string indicates what the string elements are (chars or bytes), so as long as you only manipulate strings, Emacs is able to DTRT. As soon as you manipulate actual chars, the ambiguity between chars and bytes for values [128..255] can bite you unless you're careful about how you use them (e.g. about the multibyteness of the strings with which you combine them). That's where `aset' bites. I hate `aset' on strings because it has side-effects (obviously) and because strings aren't vectors so you can't guarantee the expected efficiency, but neither are the source of the problem here. So indeed subst-char-in-string suffers similarly. Stefan