From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 15:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 14939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 14939@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.137459469723949 (code B ref -1); Tue, 23 Jul 2013 15:52:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Jul 2013 15:51:37 +0000 Received: from localhost ([127.0.0.1]:45025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1esC-0006EC-Pd for submit@debbugs.gnu.org; Tue, 23 Jul 2013 11:51:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1es9-0006Dg-DB for submit@debbugs.gnu.org; Tue, 23 Jul 2013 11:51:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1es3-0002Tu-0c for submit@debbugs.gnu.org; Tue, 23 Jul 2013 11:51:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-100.0 required=5.0 tests=BAYES_20, USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1es2-0002To-St for submit@debbugs.gnu.org; Tue, 23 Jul 2013 11:51:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1es1-0008Bu-Nn for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 11:51:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1erz-0002Sz-Ar for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 11:51:25 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:48186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1erz-0002Sl-2L for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2013 11:51:23 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6NFpKD0011017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Jul 2013 15:51:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NFpI03028064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jul 2013 15:51:19 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NFpIha007029 for ; Tue, 23 Jul 2013 15:51:18 GMT MIME-Version: 1.0 Message-ID: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> Date: Tue, 23 Jul 2013 08:51:17 -0700 (PDT) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.4 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) It is not clear what to use instead of `make-variable-frame-local'. The doc string says to "explicitly check for a frame parameter instead". What do you mean "check" for the frame parameter? When? I have code that adds a variable with a nil value as a frame parameter to a particular frame, like so: (make-variable-frame-local 'the-variable) (modify-frame-parameters the-frame '((the-variable))) That still works (the function is deprecated but presumably not desupported), but apparently I should be doing something different, in order not to use `make-variable-frame-local'. What should I be doing differently? If I remove the call to `make-variable-frame-local' then the code no longer works - the frame parameter value is not used as the variable value in code that tests the variable value. Is each piece of code that uses the value of the variable supposed to check the selected frame to see if it has a parameter, and if so, to use that frame parameter value instead of the variable value? That would be ridiculously heavy-handed. 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? In GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-07-14 on ODIEONE Bzr revision: 113423 lekktu@gmail.com-20130715004922-i67tg2ois14h3fpm Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/binary --enable-checking=3Dyes,glyphs CFLAGS=3D'-O0 -g3' CPPFLAGS=3D'-Ic:/Devel/emacs/include' LDFLAGS=3D'-Lc:/Devel/emacs/lib'' From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 17:06:01 +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: To: Drew Adams Cc: 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.13745991158483 (code B ref 14939); Tue, 23 Jul 2013 17:06:01 +0000 Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 17:05:15 +0000 Received: from localhost ([127.0.0.1]:45185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1g1R-0002Cg-Ir for submit@debbugs.gnu.org; Tue, 23 Jul 2013 13:05:14 -0400 Received: from mail-ea0-f170.google.com ([209.85.215.170]:39814) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1g1O-0002CB-FU for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 13:05:11 -0400 Received: by mail-ea0-f170.google.com with SMTP id h10so4611168eaj.15 for <14939@debbugs.gnu.org>; Tue, 23 Jul 2013 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7G4fOo/MPX9Gv4aDB0cz1NxUccl7wZpjcKS6lNQsOZc=; b=x7orNVrBtHpFZxN9ww0Te0vUEoPLOSlwJoJYY5uATeuIVVNWSiD86Jr3nlJg458Ktk wyWTB8LoyUPcm+bAt2jcZxNHrgoBA2QY1y32Xfq/hRuBs3l2O07TSsqbV4g8a+3ICeg7 O7zhTyNuGWSqDSLJ7aouNjYTfiVMjehfVNKKAMXzEKCOm46IaaSqpO5voXHzUhX5VdQ3 U2jqJ4hxeyO62aGM+brBq6gM9heYUel0Qwma2Df0UpFLYfz35RwTFH3f+lAMSauLTAP+ lxzPkf1qaKIeUeiN0Lusj+z1TtKzTe9o3YdqkLyGM5KXbu7+HqWT4EiDjoE40RxKWO5J crfA== X-Received: by 10.14.219.6 with SMTP id l6mr32704109eep.152.1374599104545; Tue, 23 Jul 2013 10:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.142.4 with HTTP; Tue, 23 Jul 2013 10:04:23 -0700 (PDT) In-Reply-To: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> From: Juanma Barranquero Date: Tue, 23 Jul 2013 19:04:23 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Jul 23, 2013 at 5:51 PM, Drew Adams wrote: > If I remove the call to `make-variable-frame-local' then > the code no longer works - the frame parameter value is not used as > the variable value in code that tests the variable value. > > Is each piece of code that uses the value of the variable supposed to > check the selected frame to see if it has a parameter, and if so, to use > that frame parameter value instead of the variable value? That would be > ridiculously heavy-handed. And still, yes. Basically, if you want to store info in a frame parameter and then use it at some other place, you should explicitly do so. The old method of allowing a third type of "automatic" variable, along global and buffer-local ones, adds complexity, had obscure non-trivial bugs and it was, in fact, almost never used. The very fact that they've been deprecated for six years and nobody has complained surely says something... > 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? 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. Juanma From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 17:17: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: To: Drew Adams Cc: 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.137459978810471 (code B ref 14939); Tue, 23 Jul 2013 17:17:02 +0000 Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 17:16:28 +0000 Received: from localhost ([127.0.0.1]:45220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1gCJ-0002io-QJ for submit@debbugs.gnu.org; Tue, 23 Jul 2013 13:16:28 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58795) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1gCH-0002ie-G4 for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 13:16:25 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r6NHGOmZ028177; Tue, 23 Jul 2013 13:16:24 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 73353B4205; Tue, 23 Jul 2013 13:16:24 -0400 (EDT) From: Stefan Monnier Message-ID: References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> Date: Tue, 23 Jul 2013 13:16:24 -0400 In-Reply-To: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> (Drew Adams's message of "Tue, 23 Jul 2013 08:51:17 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4648=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4648> : streams <1005033> : uri <1484864> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Is each piece of code that uses the value of the variable supposed to > check the selected frame to see if it has a parameter, and if so, to use > that frame parameter value instead of the variable value? Yes. > That would be ridiculously heavy-handed. Not in my experience. Stefan From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 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: To: Juanma Barranquero Cc: 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.137460334020009 (code B ref 14939); Tue, 23 Jul 2013 18:16:02 +0000 Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 18:15:40 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Tue, 23 Jul 2013 11:15:26 -0700 (PDT) From: Drew Adams References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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. From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 19:57:01 +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: To: Drew Adams Cc: Juanma Barranquero , 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.13746094052937 (code B ref 14939); Tue, 23 Jul 2013 19:57:01 +0000 Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 19:56:45 +0000 Received: from localhost ([127.0.0.1]:45424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1ihQ-0000lG-Go for submit@debbugs.gnu.org; Tue, 23 Jul 2013 15:56:44 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:35020) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1ihO-0000l4-22 for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 15:56:42 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r6NJufCm008295; Tue, 23 Jul 2013 15:56:41 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id E236BB40FF; Tue, 23 Jul 2013 15:56:40 -0400 (EDT) From: Stefan Monnier Message-ID: References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> Date: Tue, 23 Jul 2013 15:56:40 -0400 In-Reply-To: (Drew Adams's message of "Tue, 23 Jul 2013 11:15:26 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4648=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4648> : streams <1005086> : uri <1484988> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > This is a move backward, IMO. Yet, that's what we're doing and I have every intention to remove frame-local vars, so if you want your code to keep working in the future, better move away from make-variable-frame-local. > Consider minor mode `tool-bar-here-mode', If you want a frame-local minor mode, you can do (define-minor-mode foo-mode nil :variable (frame-parameter nil 'foo-mode) ...) -- Stefan From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2013 20:13: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: To: Stefan Monnier Cc: Juanma Barranquero , 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.13746103549288 (code B ref 14939); Tue, 23 Jul 2013 20:13:02 +0000 Received: (at 14939) by debbugs.gnu.org; 23 Jul 2013 20:12:34 +0000 Received: from localhost ([127.0.0.1]:45429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1iwk-0002Pj-3d for submit@debbugs.gnu.org; Tue, 23 Jul 2013 16:12:34 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:20507) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1iwh-0002PF-PS for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 16:12:32 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6NKCMXd031391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 20:12:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NKCL6D018463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 20:12:21 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NKCLWO013209; Tue, 23 Jul 2013 20:12:21 GMT MIME-Version: 1.0 Message-ID: <48c26172-6161-4aaa-a4e5-15044567d8df@default> Date: Tue, 23 Jul 2013 13:12:20 -0700 (PDT) From: Drew Adams References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > This is a move backward, IMO. >=20 > Yet, that's what we're doing and I have every intention to remove > frame-local vars, so if you want your code to keep working in the > future, better move away from make-variable-frame-local. Too bad. Still a move backward. > > Consider minor mode `tool-bar-here-mode', >=20 > If you want a frame-local minor mode, you can do > (define-minor-mode foo-mode nil > :variable (frame-parameter nil 'foo-mode) ...) Nope, not for Emacs 22. Or 23. Good to know, however, for when I need to write a library that will be useful only for Emacs 24 and later (which will happen sooner or later). From unknown Sat Sep 06 14:24:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jul 2013 00:04: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: To: Drew Adams Cc: 14939@debbugs.gnu.org Received: via spool by 14939-submit@debbugs.gnu.org id=B14939.137462420814065 (code B ref 14939); Wed, 24 Jul 2013 00:04:02 +0000 Received: (at 14939) by debbugs.gnu.org; 24 Jul 2013 00:03:28 +0000 Received: from localhost ([127.0.0.1]:45674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1mYB-0003el-So for submit@debbugs.gnu.org; Tue, 23 Jul 2013 20:03:28 -0400 Received: from mail-ee0-f52.google.com ([74.125.83.52]:53190) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V1mY9-0003eN-Km for 14939@debbugs.gnu.org; Tue, 23 Jul 2013 20:03:26 -0400 Received: by mail-ee0-f52.google.com with SMTP id c50so4870691eek.39 for <14939@debbugs.gnu.org>; Tue, 23 Jul 2013 17:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LuVY0VLyAikwoHa6Rb1ZHT908cDua5Ek5ug+qJ/fuOQ=; b=BRxn6y5BHWsyoKE+AdsO9UcN64ZBY8xdngC39hAKSydJsrw+2cEorULAvhBV2gF0Gw 7DgdBl/84TjbiKJWMOZjTK0UWOYTw4tdFb4eDEcUaJ1FasclzUEuaGtTRD8GwsXsuf5C 3Q6zrRQDWGqvq3tkPvnn/n39xFP7k7b9sws/Q7x9oSq4CnS6mAyynPOu/SoyWwbSpTTV 7MskKX97BJyjYgGueFDSYRo2JSUN6NZ09RZC18w1CgwSuIZxsr4VOxyyGpi5fgO7W+eh WbG5YjPLX+dHDJKaIk44vdezpkgr8oR41RmZcTTFYbWi6RIPvDXUw25yetfSFUK2hdmj nRIw== X-Received: by 10.15.36.133 with SMTP id i5mr35250593eev.52.1374624199892; Tue, 23 Jul 2013 17:03:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.142.4 with HTTP; Tue, 23 Jul 2013 17:02:39 -0700 (PDT) In-Reply-To: References: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default> From: Juanma Barranquero Date: Wed, 24 Jul 2013 02:02:39 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Jul 23, 2013 at 8:15 PM, Drew Adams wrote: > 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. Will all due respect, Drew, it's your argument that I find fallacious. You say yourself that your code is not failing, and yet we're discussing this in a bug thread that you started *because* of the deprecation... So yes, if you're the only one to take that step in five or six years, I'd say that speaks quite loudly. People who make heavy use of frame-local variables and is worried about the deprecation should surely take notice and bring the issue, but none did. I'd bet the reason is, simply, that not many people use that feature. When the whole issue of make-variable-frame-local was discussed in emacs-devel in 2007, I did a search through the 'net and didn't really find many uses of it (as in, almost none). I'd bet the number has not grown since then. > 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? That's for Stefan to decide (and he already has made his opinion clear), but my answer would be: Not because some subtle bugs, but because it makes Emacs source code (and manuals) more complex, and it is not really used at all, except for a few very isolate cases. And removing frame-local variables will be back-incompatible, but easily fixable via normal frame parameters, which is a bit less convenient, but vastly clearer. > 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. Frame-local and buffer-local is currently impossible because there were subtle interactions; you can check the emacs-devel archives if you're interested, but IIRC there was a case where *accessing* the value of a simultaneously buffer-local/frame-local variable could alter what it would return *later* when accessed as buffer-local or frame-local. Madness. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 08 00:26:33 2014 Received: (at control) by debbugs.gnu.org; 8 Feb 2014 05:26:33 +0000 Received: from localhost ([127.0.0.1]:56083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Qy-0001vg-Pg for submit@debbugs.gnu.org; Sat, 08 Feb 2014 00:26:33 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:54159) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WC0Qw-0001vV-Bu for control@debbugs.gnu.org; Sat, 08 Feb 2014 00:26:30 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WC0Qh-0005kB-DI for control@debbugs.gnu.org; Sat, 08 Feb 2014 06:26:15 +0100 Date: Fri, 07 Feb 2014 21:25:07 -0800 Message-Id: <87bnyi2n2k.fsf@building.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #14939 X-MailScanner-ID: 1WC0Qh-0005kB-DI X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392441977.28103@frNeuleWCZC5F7P0JADkJQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 14939 wontfix close 14939