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.