bug#6203: Frame-local variables break let-binding

bug#6203: Frame-local variables break let-binding

[Nathan Weizenbaum]

[-- 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 --]

bug#6203: Frame-local variables break let-binding

[Stefan Monnier]

> 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

bug#6203: Frame-local variables break let-binding

[Nathan Weizenbaum]

[-- 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 --]

bug#6203: Frame-local variables break let-binding

[Stefan Monnier]

> 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

bug#6203: Frame-local variables break let-binding

[Nathan Weizenbaum]

[-- 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 --]

bug#6203: Frame-local variables break let-binding

[Stefan Monnier]

> 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

bug#6203: Frame-local variables break let-binding

[Nathan Weizenbaum]

[-- 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 --]

bug#6203: Frame-local variables break let-binding

[Juri Linkov]

>    (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/

bug#6203: Frame-local variables break let-binding

[Stefan Monnier]

> 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

bug#6203: Frame-local variables break let-binding

[Tom Tromey]

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