From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local variables affect general-purpose functions Date: Thu, 27 Mar 2014 19:17:46 +0200 Message-ID: <83ppl7y30l.fsf@gnu.org> References: <831txozsqa.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1395940674 14190 80.91.229.3 (27 Mar 2014 17:17:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2014 17:17:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 27 18:18:03 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WTDwI-0007ZC-IL for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 18:18:02 +0100 Original-Received: from localhost ([::1]:55104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTDwI-00023z-2f for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 13:18:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTDwA-00020z-5A for emacs-devel@gnu.org; Thu, 27 Mar 2014 13:17:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WTDw5-0001XX-1T for emacs-devel@gnu.org; Thu, 27 Mar 2014 13:17:54 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:55304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTDw4-0001XE-Kr for emacs-devel@gnu.org; Thu, 27 Mar 2014 13:17:48 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N3300D00UIPQP00@mtaout28.012.net.il> for emacs-devel@gnu.org; Thu, 27 Mar 2014 19:17:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3300CF8UP7BB20@mtaout28.012.net.il>; Thu, 27 Mar 2014 19:17:31 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171038 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Thu, 27 Mar 2014 10:17:23 -0400 >=20 > > M-x find-file-literally RET some-file RET > > M-x set-variable RET case-fold-search RET t RET > > M-: (chars-equal ?=E0 ?=C0) RET >=20 > > This produces nil, although the characters should compare equal u= nder > > case-fold-search. Why? Because we are in a unibyte buffer, wher= e > > values between 128 and 255 are interpreted as eight-bit raw bytes= , not > > as Latin characters, and raw bytes don't have lower/upper-case pa= irs. >=20 > I agree with Paul on this one: this should be fixed to disregard > unibyte setting. `char-equal' compares chars, not bytes (use `eq' > for bytes). > It's an old backward compatibility hack that should go. Paul seemed to say something more broad: that _all_ behaviors specifi= c to unibyte buffers should go away. Do you agree? Anyway, what should replace those hacks? Arbitrarily interpreting ra= w bytes as Latin characters is not TRT, IMO. Actually, in the above case, we could simply make char-equal disregar= d case-fold-search in unibyte buffers -- that would give you and Paul what you want, but also keep backward compatibility (except for ASCII characters). > > The question is: do we want to do something about that? >=20 > Not sure. It's hard to find all occurrences of this problem. > And I don't think we can find a "general" solution: each case might= be > best solved in a different way. Furthermore the right solution wil= l > sometimes (often?) be to throw away the current functionality and > replace it with something different. Maybe so, but something like (with-buffer-defaults BODY) might be the solution, and should be easy enough to implement. Or maybe some other way of telling primitives: don't apply buffer-specific behavior to this code. > % grep with-case-table **/*.el > emacs-lisp/lisp-mode.el: "eval-and-compile= " "eval-when-compile" "with-case-table" > leim/quail/sisheng.el: (with-case-table (standard-case-table) > mail/smtpmail.el: (with-case-table ascii-case-= table ;Why? > subr.el:(defmacro with-case-table (table &rest body) >=20 > And the only uses of with-case-table are in lisp/leim/quail/sisheng= .el > (where it sets the standard case table, so it should have no effect= ) and > in lisp/mail/smtpmail.el (where it uses ascii-case-table but should= only > apply it to ASCII text, so it could just as well use the standard c= ase > table). >=20 > And then we can use the Unicode 'case tables' as recently discussed= . > Patch for that welcome on trunk. OK.