bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Drew Adams]

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''

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Juanma Barranquero]

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

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Stefan Monnier]

> 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

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Drew Adams]

> 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.

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Stefan Monnier]

> 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

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Drew Adams]

> > 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).

bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?

[Juanma Barranquero]

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.