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: Buffer-local variables affect general-purpose functions Date: Thu, 27 Mar 2014 10:17:23 -0400 Message-ID: References: <831txozsqa.fsf@gnu.org> 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 1395929859 28519 80.91.229.3 (27 Mar 2014 14:17:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2014 14:17:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 27 15:17:47 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 1WTB7p-0003Ts-MM for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 15:17:45 +0100 Original-Received: from localhost ([::1]:53929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTB7o-0004U0-Np for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 10:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTB7e-0004Ts-5Y for emacs-devel@gnu.org; Thu, 27 Mar 2014 10:17:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WTB7V-0001fx-MS for emacs-devel@gnu.org; Thu, 27 Mar 2014 10:17:34 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTB7V-0001fn-G6; Thu, 27 Mar 2014 10:17:25 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s2REHNjn003326; Thu, 27 Mar 2014 10:17:23 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 2C16D60217; Thu, 27 Mar 2014 10:17:23 -0400 (EDT) In-Reply-To: <831txozsqa.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Mar 2014 21:04:45 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4894=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4894> : inlines <652> : streams <1145567> : uri <1711551> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:171031 Archived-At: > 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 > This produces nil, although the characters should compare equal under > case-fold-search. Why? Because we are in a unibyte buffer, where > 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 pairs. 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. > Another example, from the same sequence of commands above, is the fact > that setting case-fold-search for the buffer affects comparison of > characters that don't belong to the buffer, merely because that buffer > happens to be current at the moment of comparison. IIUC this is the kind of problem you really want to talk about in this thread, and yes, it's a problem. Usually case-fold-search is let-bound rather than set buffer-locally, but we have similar problems with syntax-tables, case-tables, etc... > The question is: do we want to do something about that? 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 will sometimes (often?) be to throw away the current functionality and replace it with something different. But we can definitely try to solve it on a case-by-case basis. > Yet another example is 'downcase' and 'upcase' functions -- they use > case tables local to the current buffer, even when the functions they > are applied to characters and strings not from the buffer. The solution here is simple: throw away buffer-local case-tables. AFAICT, set-case-table is used at only one place: in with-case-table. % grep set-case-table **/*.el=20=20=20=20 emacs-lisp/cl-lib.el:;; (gv-define-simple-setter current-case-table set-= case-table) subr.el: (progn (set-case-table ,table) subr.el: (set-case-table ,old-case-table)))))) So the only use of set-case-table is in with-case-table. % 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 ;W= hy? subr.el:(defmacro with-case-table (table &rest body) 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 case table). And then we can use the Unicode 'case tables' as recently discussed. Patch for that welcome on trunk. > This could produce subtle bugs, and is certainly confusing and > unexpected, at least by some. Agreed. Stefan