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: (aset UNIBYTE-STRING MULTIBYTE-CHAR) Date: Thu, 14 Feb 2008 23:27:50 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203049686 15605 80.91.229.12 (15 Feb 2008 04:28:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Feb 2008 04:28:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 15 05:28:29 2008 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 1JPsBZ-00057t-1G for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2008 05:28:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPsB5-0001wr-Cf for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2008 23:27:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JPsB0-0001uo-Ki for emacs-devel@gnu.org; Thu, 14 Feb 2008 23:27:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JPsAz-0001tJ-Hs for emacs-devel@gnu.org; Thu, 14 Feb 2008 23:27:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPsAz-0001t6-Bh for emacs-devel@gnu.org; Thu, 14 Feb 2008 23:27:53 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JPsAy-0007LT-Ov for emacs-devel@gnu.org; Thu, 14 Feb 2008 23:27:53 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANujtEdMCpRc/2dsb2JhbACvIn8 X-IronPort-AV: E=Sophos;i="4.25,356,1199682000"; d="scan'208";a="14520476" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 14 Feb 2008 23:27:51 -0500 Original-Received: from pastel.home ([76.10.148.92]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id VGQ03551; Thu, 14 Feb 2008 23:27:51 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 48FE27F29; Thu, 14 Feb 2008 23:27:50 -0500 (EST) In-Reply-To: (Kenichi Handa's message of "Fri, 15 Feb 2008 10:39:01 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: 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:89134 Archived-At: > Even if the code is very bad, it worked in Emacs 22. > If it doesn't work in Emacs 23, it's a regression. If it makes them improve their code, it's an ... improvement. > The problem here is that (make-string 1 ?a) is a unibyte > string, but "a" generated by buffer-substring on a multibyte > buffer is a multibyte string. The result of concatinating > them is also multibyte. So, the multibyteness of strings is > difficult of expect. Indeed. To work around this problem, my locally hacked Emacs distinguishes between unibyte strings (byte-length < 0), multibyte strings (byte-length > char-length), and "anybyte" strings (byte-length = char-length). > If we are going to inhibit aset on multibyte strings, We can just inhibit aset if it requires changes the string's byte-length or multibyte-ness. > I think we should inhibit aset on any strings to avoid > a further confusion. And that's indeed what my locally hacked Emacs does. >> When weighed against the *very* rare cases where aset is used (let >> alone the even more rare cases where aset is actually useful and >> convenient), the choice is trivial (for me anyway). > Then, shouldn't we start the experiment of inhibitting aset > on strings just now? But I do not think we're ready for that. Maybe 10 years from now... Stefan