* bug#6203: Frame-local variables break let-binding
@ 2010-05-16 22:18 Nathan Weizenbaum
2010-05-17 13:45 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Weizenbaum @ 2010-05-16 22:18 UTC (permalink / raw)
To: 6203
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
I've run into a bug with GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+
Version 2.16.1, checked out from the repo a week or so ago). Let-binding
frame-local variables doesn't work: although the let-bound value is correct
within the `let', it doesn't get reset after the `let'. To reproduce, just
run http://gist.github.com/403208.
[-- Attachment #2: Type: text/html, Size: 398 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-16 22:18 bug#6203: Frame-local variables break let-binding Nathan Weizenbaum
@ 2010-05-17 13:45 ` Stefan Monnier
2010-05-17 17:12 ` Nathan Weizenbaum
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2010-05-17 13:45 UTC (permalink / raw)
To: Nathan Weizenbaum; +Cc: 6203
> I've run into a bug with GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+
> Version 2.16.1, checked out from the repo a week or so ago). Let-binding
> frame-local variables doesn't work: although the let-bound value is correct
> within the `let', it doesn't get reset after the `let'. To reproduce, just
> run http://gist.github.com/403208.
I definitely cannot reproduce the behavior you show on that page:
The code stops at "(message "Before: %d" foo)" because foo has
value nil at that point which is incompatible with the %d format.
If I get rid of this bug, then I bump into the next error which is that
`let' raises "Frame-local vars cannot be let-bound".
Note that frame-local variables have been deprecated since Emacs-22.2,
and I definitely intend to remove support for them (tho for Emacs-24.1,
the plan is currently only to remove support for let-binding them).
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-17 13:45 ` Stefan Monnier
@ 2010-05-17 17:12 ` Nathan Weizenbaum
2010-05-17 19:48 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Weizenbaum @ 2010-05-17 17:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6203
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
Sorry, the "%d" thing was a bug. It looks like the let-binding error was
introduced after my last checkout, though, so I guess that's deal with.
This all raises the issue, though: what's the accepted replacement for
frame-local variables, and why are they deprecated in the first place? My
package has rather a few of them, and it's very useful to be able to use
them like variables. I want to make them available for user customization,
let-bind them, and use them without having to go through lots of manual
frame-parameter rigamarole each time. I would rather not break any user
customizations using these variables. So what should I do?
On Mon, May 17, 2010 at 6:45 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
> > I've run into a bug with GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+
> > Version 2.16.1, checked out from the repo a week or so ago). Let-binding
> > frame-local variables doesn't work: although the let-bound value is
> correct
> > within the `let', it doesn't get reset after the `let'. To reproduce,
> just
> > run http://gist.github.com/403208.
>
> I definitely cannot reproduce the behavior you show on that page:
> The code stops at "(message "Before: %d" foo)" because foo has
> value nil at that point which is incompatible with the %d format.
> If I get rid of this bug, then I bump into the next error which is that
> `let' raises "Frame-local vars cannot be let-bound".
>
> Note that frame-local variables have been deprecated since Emacs-22.2,
> and I definitely intend to remove support for them (tho for Emacs-24.1,
> the plan is currently only to remove support for let-binding them).
>
>
> Stefan
>
[-- Attachment #2: Type: text/html, Size: 2157 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-17 17:12 ` Nathan Weizenbaum
@ 2010-05-17 19:48 ` Stefan Monnier
2010-05-17 20:10 ` Nathan Weizenbaum
[not found] ` <m3iq41trka.fsf@fleche.redhat.com>
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Monnier @ 2010-05-17 19:48 UTC (permalink / raw)
To: Nathan Weizenbaum; +Cc: 6203
> This all raises the issue, though: what's the accepted replacement for
> frame-local variables,
frame-parameters
> and why are they deprecated in the first place?
Because OT1H they're very little used, and OTOH they're a pain in the
rear to support and maintain because of all kinds of corner cases, and
it'll only get better with the addition of concurrency and/or
lexical scoping.
> My package has rather a few of them, and it's very useful to be able
> to use them like variables. I want to make them available for user
> customization, let-bind them, and use them without having to go
> through lots of manual frame-parameter rigamarole each time. I would
> rather not break any user customizations using these variables.
> So what should I do?
Use frame-parameters. Note that until Emacs-24 is released, that gives
you a fair bit of time to deal with it.
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-17 19:48 ` Stefan Monnier
@ 2010-05-17 20:10 ` Nathan Weizenbaum
2010-05-18 15:29 ` Stefan Monnier
[not found] ` <m3iq41trka.fsf@fleche.redhat.com>
1 sibling, 1 reply; 10+ messages in thread
From: Nathan Weizenbaum @ 2010-05-17 20:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6203
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
But frame-parameters have to be manually managed with frame-parameter, no?
Even ignoring compatibility for user-facing configuration, it seems really
annoying to have to call frame-parameter and set-frame-parameter all the
time, especially if you're trying to simulate `let'.
Are there at least any plans for a nicer API for working with what used to
be frame-local variables?
On Mon, May 17, 2010 at 12:48 PM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:
> > This all raises the issue, though: what's the accepted replacement for
> > frame-local variables,
>
> frame-parameters
>
> > and why are they deprecated in the first place?
>
> Because OT1H they're very little used, and OTOH they're a pain in the
> rear to support and maintain because of all kinds of corner cases, and
> it'll only get better with the addition of concurrency and/or
> lexical scoping.
>
> > My package has rather a few of them, and it's very useful to be able
> > to use them like variables. I want to make them available for user
> > customization, let-bind them, and use them without having to go
> > through lots of manual frame-parameter rigamarole each time. I would
> > rather not break any user customizations using these variables.
> > So what should I do?
>
> Use frame-parameters. Note that until Emacs-24 is released, that gives
> you a fair bit of time to deal with it.
>
>
> Stefan
>
[-- Attachment #2: Type: text/html, Size: 1894 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-17 20:10 ` Nathan Weizenbaum
@ 2010-05-18 15:29 ` Stefan Monnier
2010-05-18 21:32 ` Nathan Weizenbaum
2010-05-18 22:42 ` Juri Linkov
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Monnier @ 2010-05-18 15:29 UTC (permalink / raw)
To: Nathan Weizenbaum; +Cc: 6203
> But frame-parameters have to be manually managed with frame-parameter, no?
Sounds obvious, doesn't it?
> Even ignoring compatibility for user-facing configuration, it seems really
> annoying to have to call frame-parameter and set-frame-parameter all the
> time, especially if you're trying to simulate `let'.
No, it really doesn't seem particularly annoying:
(require 'cl)
(letf (((frame-parameter <foo>) 'newvalue)) <blabla>)
the same holds for symbol properties, process properties, window
parameters, terminal parameters, ...
> Are there at least any plans for a nicer API for working with what used to
> be frame-local variables?
BTW, since frame-parameters have been very rarely used and you seem to
use them "extensively", I'm curious: what do you use them for
(i.e. what kind of data do you keep there, and why do you need to
let-(re)bind it)?
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-18 15:29 ` Stefan Monnier
@ 2010-05-18 21:32 ` Nathan Weizenbaum
2010-05-18 22:42 ` Juri Linkov
1 sibling, 0 replies; 10+ messages in thread
From: Nathan Weizenbaum @ 2010-05-18 21:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 6203
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
letf and setf are okay as work-arounds, I suppose.
The package I use these for is
http://github.com/nex3/perspective-el/blob/master/perspective.el. Each frame
keeps track of a separate set of workspaces, as well as various other useful
variables (the current workspace, previous workspace, etc.).
On Tue, May 18, 2010 at 8:29 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
> > But frame-parameters have to be manually managed with frame-parameter,
> no?
>
> Sounds obvious, doesn't it?
>
> > Even ignoring compatibility for user-facing configuration, it seems
> really
> > annoying to have to call frame-parameter and set-frame-parameter all the
> > time, especially if you're trying to simulate `let'.
>
> No, it really doesn't seem particularly annoying:
>
> (require 'cl)
> (letf (((frame-parameter <foo>) 'newvalue)) <blabla>)
>
> the same holds for symbol properties, process properties, window
> parameters, terminal parameters, ...
>
> > Are there at least any plans for a nicer API for working with what used
> to
> > be frame-local variables?
>
> BTW, since frame-parameters have been very rarely used and you seem to
> use them "extensively", I'm curious: what do you use them for
> (i.e. what kind of data do you keep there, and why do you need to
> let-(re)bind it)?
>
>
> Stefan
>
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-18 15:29 ` Stefan Monnier
2010-05-18 21:32 ` Nathan Weizenbaum
@ 2010-05-18 22:42 ` Juri Linkov
2010-05-19 2:08 ` Stefan Monnier
1 sibling, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2010-05-18 22:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Nathan Weizenbaum, 6203
> (require 'cl)
> (letf (((frame-parameter <foo>) 'newvalue)) <blabla>)
>
> the same holds for symbol properties, process properties, window
> parameters, terminal parameters, ...
BTW, this doesn't work for window parameters. Looks like an omission:
=== modified file 'lisp/emacs-lisp/cl-macs.el'
--- lisp/emacs-lisp/cl-macs.el 2010-05-05 03:45:21 +0000
+++ lisp/emacs-lisp/cl-macs.el 2010-05-18 22:42:46 +0000
@@ -1813,6 +1813,7 @@ (defsetf window-dedicated-p set-window-d
(defsetf window-height () (store)
(list 'progn (list 'enlarge-window (list '- store '(window-height))) store))
(defsetf window-hscroll set-window-hscroll)
+(defsetf window-parameter set-window-parameter)
(defsetf window-point set-window-point)
(defsetf window-start set-window-start)
(defsetf window-width () (store)
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
2010-05-18 22:42 ` Juri Linkov
@ 2010-05-19 2:08 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2010-05-19 2:08 UTC (permalink / raw)
To: Juri Linkov; +Cc: Nathan Weizenbaum, 6203
> BTW, this doesn't work for window parameters. Looks like an omission:
[...]
> +(defsetf window-parameter set-window-parameter)
Indeed, feel fre to install it,
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#6203: Frame-local variables break let-binding
[not found] ` <jwvhbjlkx0g.fsf-monnier+emacs@gnu.org>
@ 2010-07-27 14:49 ` Tom Tromey
0 siblings, 0 replies; 10+ messages in thread
From: Tom Tromey @ 2010-07-27 14:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Nathan Weizenbaum, 6203
Tom> At least for concurrency they have the same problems as frame-locals.
Stefan> Not sure what problem you're thinking of.
All I mean is that we haven't modified the C code to make
keyboard-locals interact properly with multiple threads. The other
differences aren't super important for concurrency in that I think they
don't make a big difference in terms of implementation effort.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-07-27 14:49 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-16 22:18 bug#6203: Frame-local variables break let-binding Nathan Weizenbaum
2010-05-17 13:45 ` Stefan Monnier
2010-05-17 17:12 ` Nathan Weizenbaum
2010-05-17 19:48 ` Stefan Monnier
2010-05-17 20:10 ` Nathan Weizenbaum
2010-05-18 15:29 ` Stefan Monnier
2010-05-18 21:32 ` Nathan Weizenbaum
2010-05-18 22:42 ` Juri Linkov
2010-05-19 2:08 ` Stefan Monnier
[not found] ` <m3iq41trka.fsf@fleche.redhat.com>
[not found] ` <jwvhbjlkx0g.fsf-monnier+emacs@gnu.org>
2010-07-27 14:49 ` Tom Tromey
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.