From: Juanma Barranquero <lekktu@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 14939@debbugs.gnu.org
Subject: bug#14939: 24.3.50; `make-variable-frame-local' deprecation - alternative?
Date: Tue, 23 Jul 2013 19:04:23 +0200 [thread overview]
Message-ID: <CAAeL0ST+AKdOEpVbhiRiAohkbOfg1NAK5YEXPwqvCVviLN_L=Q@mail.gmail.com> (raw)
In-Reply-To: <9c76d260-9793-4ed4-a3b5-fc9aca408034@default>
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
next prev parent reply other threads:[~2013-07-23 17:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAeL0ST+AKdOEpVbhiRiAohkbOfg1NAK5YEXPwqvCVviLN_L=Q@mail.gmail.com' \
--to=lekktu@gmail.com \
--cc=14939@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).