From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Date: Tue, 23 Jul 2013 11:15:26 -0700 (PDT) Message-ID: References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1374603374 9010 80.91.229.3 (23 Jul 2013 18:16:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2013 18:16:14 +0000 (UTC) Cc: 14939@debbugs.gnu.org To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 23 20:16:12 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1V1h88-0001WO-3p for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jul 2013 20:16:12 +0200 Original-Received: from localhost ([::1]:35672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1h87-0003MW-LK for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jul 2013 14:16:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1h7z-0003MO-V5 for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 14:16:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1h7y-0007mn-Hp for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 14:16:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1h7y-0007mi-F3 for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 14:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V1h7y-0005Dp-3m for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 14:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 18:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.137460334020009 (code B ref 14939); Tue, 23 Jul 2013 18:16:02 +0000 Original-Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 18:15:40 +0000 Original-Received: from localhost ([127.0.0.1]:45275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1h7b-0005Ca-EX for submit@debbugs.gnu.org; Tue, 23 Jul 2013 14:15:39 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22812) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1h7Y-0005Bs-He for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 14:15:37 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6NIFSFf004821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 18:15:29 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NIFRGM013723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 18:15:28 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NIFRtE003669; Tue, 23 Jul 2013 18:15:27 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76606 Archived-At: > The very fact that they've been deprecated for six years and nobody has > complained surely says something... That's fallacious. My code has been working fine for those six years, and still works fine, because deprecation does not mean desupport. IOW, if it still works, why would people think to complain? "The very fact", indeed - it "surely" does not say anything at all. > > Please advise. Is this just a problem of unclear doc (it does not > > reallyh tell you what to do in place of using > > `make-variable-frame-local')? Or is the deprecation of this function > > misguided, because there is no good replacement for it? >=20 > Likely you don't really use that many frame-local variables. You can > easily write a couple of macros or functions to set and check the > value of one variable taking into account the possible existence of a > frame-local version (as a frame parameter). Isn't that convenient as > the old method? No, but it won't bite you unexpectedly, and would be > clearer for anyone reading the code. Providing a library for others means that they can use the variable. They will not necessarily know or care that it is frame-local. If they test the value in a given frame they should get the frame-local value and any resulting behavior. They will not know about any special access macro or know to test for a frame parameter. This does not make sense, IMO. Consider minor mode `tool-bar-here-mode', which sets its mode variable to be frame-local. I have updated the minor-mode command code to now also add frame parameter `tool-bar-here-mode' with the current value. But a user will not know, and should not need to care, about the frame parameter. Code like this in the same library will need to change: (define-key global-map [menu-bar pop-up-tool-bar] '(menu-item "Buttons" show-tool-bar-for-one-command :visible (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode)) :enable (and tool-bar-pop-up-mode (not tool-bar-mode) (not tool-bar-here-mode)) :help "Use tool bar for one command")) I can do that, but yes, the result is heavy-handed. Likewise, in minor-mode `tool-bar-pop-up-mode' I test and turn off `tool-bar-here-mode' if that mode variable is set in the selected frame. There too I will need to fiddle with frame parameters instead. And yet again in command `show-tool-bar-for-one-command'. All of this jumping through (ugly!) hoops is bad enough for my own code. But the mode and its variable are general, and can be used by other users and other code. The author of that code will also (a) need to know about this back-door frame-parameter-as-mode-variable stuff and (b) fiddle with it herself. You say that there are some subtle bugs. Well, at least for my code that uses `make-variable-frame-local' I have never run into a problem. Why remove the simple use of frame-local variables in general just because there might be some corner-case subtle bugs somewhere? This is a move backward, IMO. Without knowing just what problems you are alluding to, I would guess that they might involve variable capture when there are a mix of frame-local, buffer-local, and local variables with the same name. If that's the problem then instead of just throwing out the frame-local baby with the yes-there-are-some-subtle-name-capture-problems bathwater, just advise users of frame-local variables to not use the same names for other kinds of variables. That's not foolproof, obviously (different libraries or users can create variables that happen to have the same name etc.), but it's a lot better than tossing frame-local altogether just because unrestricted use of it can in some cases lead to subtle name-capture bugs. We don't throw out Lisp macros just because someone can (easily!) shoot herself in the foot with name capture. Please reconsider this slash-&-burn "simplification" policy.