From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: Crashes with non-default language environments Date: Tue, 12 Feb 2008 11:29:55 -0500 Message-ID: References: <87y79wve9b.fsf@jurta.org> <87zlu96bp2.fsf@jurta.org> <87prv4l96f.fsf@jurta.org> <87lk5scl3a.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1202833861 9648 80.91.229.12 (12 Feb 2008 16:31:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Feb 2008 16:31:01 +0000 (UTC) Cc: juri@jurta.org, emacs-pretest-bug@gnu.org, miles@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 12 17:31:21 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 1JOy1r-0007i1-RQ for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2008 17:30:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOy1O-00070Q-A7 for ged-emacs-devel@m.gmane.org; Tue, 12 Feb 2008 11:30:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JOy1J-0006zB-1g for emacs-devel@gnu.org; Tue, 12 Feb 2008 11:30:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JOy1G-0006yS-BP for emacs-devel@gnu.org; Tue, 12 Feb 2008 11:30:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOy1G-0006yO-7S for emacs-devel@gnu.org; Tue, 12 Feb 2008 11:30:06 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JOy1G-0001SP-5P for emacs-devel@gnu.org; Tue, 12 Feb 2008 11:30:06 -0500 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JOy1F-0006Ik-LY for emacs-pretest-bug@gnu.org; Tue, 12 Feb 2008 11:30:05 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JOy1C-0001RR-Qc for emacs-pretest-bug@gnu.org; Tue, 12 Feb 2008 11:30:05 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JOy19-0001Pw-0S; Tue, 12 Feb 2008 11:29:59 -0500 Original-Received: from ceviche.home (vpn-132-204-232-187.acd.umontreal.ca [132.204.232.187]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m1CGU34V013792; Tue, 12 Feb 2008 11:30:03 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id DD96EB40DF; Tue, 12 Feb 2008 11:29:55 -0500 (EST) In-Reply-To: (Kenichi Handa's message of "Tue, 12 Feb 2008 20:41:48 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered HAS_X_HELO=0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-detected-kernel: by monty-python.gnu.org: 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:88879 gmane.emacs.pretest.bugs:21050 Archived-At: >> Oh, that's right, we still don't have it. We only have the 3 variants >> on the uni->multi, but not on the multi->uni. >> I guess now is a good time to introduce it. > But, even if we implement string-to-unibyte, it should be > used for a string containing only ascii and eight-bit chars. > And in that case, string-make-unibyte behaves exactly the > same as string-to-unibyte. No it would be different: it would also signal an error if some non-binary char is found. (I might potentially be convinced that it's OK to additionally accept the 128-255 latin1 chars as alternatives to eight-bit chars, since they now get character codes 128-255). > We now have > `list-to-raw-string-whose-bytes-in-memory-should-have-exactly-the-same-values-as-the-elements-of-this-list'; > that is `unibyte-string' Yes, thanks. I didn't know about it. It's a great addition (tho the name might be a bit short for Miles's tastes, we may want to add list-to-raw-string-whose-bytes-in-memory-should-have-exactly-the-same-values-as-the-elements-of-this-list' as an alias for it ;-). Stefan