From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/69676 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: mm-with-unibyte-current-buffer Date: Tue, 11 May 2010 10:29:30 +0900 Organization: Emacsen advocacy group Message-ID: References: <83y6frptd7.fsf@gnu.org> <83tyqfppab.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1273541411 21656 80.91.229.12 (11 May 2010 01:30:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 May 2010 01:30:11 +0000 (UTC) Cc: Stefan Monnier , ding@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 11 03:30:09 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OBeIT-0007cY-8T for ged-emacs-devel@m.gmane.org; Tue, 11 May 2010 03:30:09 +0200 Original-Received: from localhost ([127.0.0.1]:48101 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBeIS-00049i-H2 for ged-emacs-devel@m.gmane.org; Mon, 10 May 2010 21:30:08 -0400 Original-Received: from [140.186.70.92] (port=58364 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBeIJ-000496-51 for emacs-devel@gnu.org; Mon, 10 May 2010 21:30:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBeIE-0007JJ-QJ for emacs-devel@gnu.org; Mon, 10 May 2010 21:29:59 -0400 Original-Received: from orlando.hostforweb.net ([216.246.45.90]:42094) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBeIE-0007JA-K2; Mon, 10 May 2010 21:29:54 -0400 Original-Received: from localhost ([127.0.0.1]:44733) by orlando.hostforweb.net with esmtpa (Exim 4.69) (envelope-from ) id 1OBeI7-0004yl-UQ; Mon, 10 May 2010 20:29:48 -0500 X-Hashcash: 1:20:100511:eliz@gnu.org::oqKjOo95QnMU3mNl:000001MEM X-Hashcash: 1:20:100511:monnier@iro.umontreal.ca::FRdNZxs1VjkNAJDQ:0000000000000000000000000000000000000Ave9 X-Hashcash: 1:20:100511:ding@gnus.org::s9Y8q8u8PX9LE8Yg:00001xte X-Hashcash: 1:20:100511:emacs-devel@gnu.org::JGhuJEL1xJ8rhIeW:0000000000000000000000000000000000000000001Jkr X-Face: #kKnN,xUnmKia.'[pp`; Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu; B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:XHzh7NB8eV0MsYWOsL88JQD0tZU= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-detected-operating-system: by eggs.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:124688 gmane.emacs.gnus.general:69676 Archived-At: >>>>> Eli Zaretskii wrote: >> From: Stefan Monnier >> Date: Mon, 10 May 2010 13:51:27 -0400 >> Cc: Katsumi Yamaoka , ding@gnus.org, emacs-devel@gnu.org >> >>> Binding the value of enable-multibyte-characters may be a no-no, but >>> _testing_ its value is still possible. So I see no reason to >>> set-buffer-multibyte unconditionally, because you may already be in a >>> unibyte buffer. >> >> But calling set-buffer-multibyte with the current value is harmless (it >> checks a returns right away if there's nothing to do; this check might >> even be faster than doing it in Elisp). > That's true, but the unconditional call `(set-buffer-multibyte t)' at > the end of the macro is _not_ harmless, if the buffer was originally a > unibyte one. The macro runs `(set-buffer-multibyte nil)' first regardless of the multibyteness of a buffer whatever data are there, and runs `(set-buffer-multibyte t)' finally. I don't recall what kind of data were there, but in the early days of the Emacs 23 development I saw data were made broken. Did you mean such a trouble will never happen with the released Emacs versions? (Note: Gnus supports Emacs 21~24, XEmacs 21.4&21.5, and SXEmacs.)