[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternativ
bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?
Tue, 23 Jul 2013 19:04:23 +0200
On Tue, Jul 23, 2013 at 5:51 PM, Drew Adams <address@hidden> 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.