* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? @ 2013-07-23 15:51 Drew Adams 2013-07-23 17:04 ` Juanma Barranquero 2013-07-23 17:16 ` Stefan Monnier 0 siblings, 2 replies; 7+ messages in thread From: Drew Adams @ 2013-07-23 15:51 UTC (permalink / raw To: 14939 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=/c/Devel/emacs/binary --enable-checking=yes,glyphs CFLAGS='-O0 -g3' CPPFLAGS='-Ic:/Devel/emacs/include' LDFLAGS='-Lc:/Devel/emacs/lib'' ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 15:51 bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Drew Adams @ 2013-07-23 17:04 ` Juanma Barranquero 2013-07-23 18:15 ` Drew Adams 2013-07-23 17:16 ` Stefan Monnier 1 sibling, 1 reply; 7+ messages in thread From: Juanma Barranquero @ 2013-07-23 17:04 UTC (permalink / raw To: Drew Adams; +Cc: 14939 On Tue, Jul 23, 2013 at 5:51 PM, Drew Adams <drew.adams@oracle.com> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 17:04 ` Juanma Barranquero @ 2013-07-23 18:15 ` Drew Adams 2013-07-23 19:56 ` Stefan Monnier 2013-07-24 0:02 ` Juanma Barranquero 0 siblings, 2 replies; 7+ messages in thread From: Drew Adams @ 2013-07-23 18:15 UTC (permalink / raw To: Juanma Barranquero; +Cc: 14939 > 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? > > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 18:15 ` Drew Adams @ 2013-07-23 19:56 ` Stefan Monnier 2013-07-23 20:12 ` Drew Adams 2013-07-24 0:02 ` Juanma Barranquero 1 sibling, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2013-07-23 19:56 UTC (permalink / raw To: Drew Adams; +Cc: Juanma Barranquero, 14939 > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 19:56 ` Stefan Monnier @ 2013-07-23 20:12 ` Drew Adams 0 siblings, 0 replies; 7+ messages in thread From: Drew Adams @ 2013-07-23 20:12 UTC (permalink / raw To: Stefan Monnier; +Cc: Juanma Barranquero, 14939 > > 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. Too bad. Still a move backward. > > 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) ...) 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 18:15 ` Drew Adams 2013-07-23 19:56 ` Stefan Monnier @ 2013-07-24 0:02 ` Juanma Barranquero 1 sibling, 0 replies; 7+ messages in thread From: Juanma Barranquero @ 2013-07-24 0:02 UTC (permalink / raw To: Drew Adams; +Cc: 14939 On Tue, Jul 23, 2013 at 8:15 PM, Drew Adams <drew.adams@oracle.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? 2013-07-23 15:51 bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Drew Adams 2013-07-23 17:04 ` Juanma Barranquero @ 2013-07-23 17:16 ` Stefan Monnier 1 sibling, 0 replies; 7+ messages in thread From: Stefan Monnier @ 2013-07-23 17:16 UTC (permalink / raw To: Drew Adams; +Cc: 14939 > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-07-24 0:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-23 15:51 bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative? Drew Adams 2013-07-23 17:04 ` Juanma Barranquero 2013-07-23 18:15 ` Drew Adams 2013-07-23 19:56 ` Stefan Monnier 2013-07-23 20:12 ` Drew Adams 2013-07-24 0:02 ` Juanma Barranquero 2013-07-23 17:16 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.