frame-local variables weirdness

frame-local variables weirdness

[Juanma Barranquero]

After making a variable frame-local, and then buffer-local (with
`make-variable-buffer-local', not `make-local-variable') it is not
possible to set a buffer-local value for the variable:

  ELISP> (setq foo 'default)
 default
  ELISP> (make-variable-frame-local 'foo)
 foo
  ELISP> (modify-frame-parameters nil '((foo . frame)))
 nil
  ELISP> foo
 frame
  ELISP> (make-variable-buffer-local 'foo)
 foo
  ELISP> (setq foo 'bug)
 bug
  ELISP> foo
 bug
  ELISP> (frame-parameter nil 'foo)
 bug
  ELISP> (local-variable-p 'foo)
 nil

However, that doesn't happen if we first make it buffer-local, and
then frame-local:

  ELISP> (setq bar 'default)
 default
  ELISP> (make-variable-buffer-local 'bar)
 bar
  ELISP> (setq bar 'buffer)
 buffer
  ELISP> (local-variable-p 'bar)
 t
  ELISP> (make-variable-frame-local 'bar)
 bar
  ELISP> (modify-frame-parameters nil '((bar . frame)))
 nil
  ELISP> bar
 buffer
  ELISP> (kill-local-variable 'bar)
 bar
  ELISP> bar
 frame

BTW, is there a way to know when a variable is frame local?
`frame-parameter' is not enough (it could be a frame parameter and yet
not a frame local variable).

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Juanma Barranquero]

I've simplified the test.  Apparently, getting the value of a
frame-local variable negatively affects whether the variable will
afterwards be able to turn automatically buffer-local.

  (defun test (sym bug)
   (set sym 'default)
   (make-variable-frame-local sym)
   (modify-frame-parameters nil (list (cons sym 'frame)))
   (when bug
     ;; Getting the value of sym changes the result
     (symbol-value sym))
   (make-variable-buffer-local sym)
   (set sym 'local)
   (list (local-variable-p sym)       ;; should be t
         (symbol-value sym)           ;; should be 'local
         (frame-parameter nil sym)))  ;; should be 'frame

Note that passing t to the BUG argument only changes one thing: that
(symbol-value sym) is run.

 (test 'foo nil) => (t local frame)
 (test 'bar t)   => (nil local local)

BTW, is there any easy way to remove a frame parameter? Testing this
bug is a PITA because you've got to use different symbols each time...

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Richard Stallman]

I don't think that Emacs has any way to cancel what
make-variable-frame-local does.  We never tried to implement one.
Likewise there is no way to cancel what make-variable-buffer-local
does.  I am not surprised that confusion happens if you try doing both
to the same variable, because they are conflicting states.

I don't think we should try to change this now.

Re: frame-local variables weirdness

[Juanma Barranquero]

On 12/9/06, Richard Stallman <rms@gnu.org> wrote:

> I don't think that Emacs has any way to cancel what
> make-variable-frame-local does.  We never tried to implement one.

I was asking for a way to remove a frame parameter. I don't see any
remove-frame-parameter, and `modify-frame-parameters' can add and
modify values, but not remove them, IIUC.

> I am not surprised that confusion happens if you try doing both
> to the same variable, because they are conflicting states.

They should not be conflicting. The docstring of
`make-variable-frame-local' says: "Buffer-local bindings take
precedence over frame-local bindings." I would expect that, after

  (make-variable-frame-local var)
  (make-variable-buffer-local var)

any (set var VALUE) would set a buffer-local value.

> I don't think we should try to change this now.

It is a bug nonetheless. We should take note somewhere.

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 12/5/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> BTW, is there a way to know when a variable is frame local?
> `frame-parameter' is not enough (it could be a frame parameter and yet
> not a frame local variable).

After asking that question I've found `variable-binding-locus', which
allows a trivial implementation of `frame-local-variable-p' (à la
`local-variable-p'), but I still don't see an easy way to implement a
frame-local version of `local-variable-if-set-p'.

                    /L/e/k/t/u

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: frame-local variables weirdness

[Stefan Monnier]

> `local-variable-p'), but I still don't see an easy way to implement a
> frame-local version of `local-variable-if-set-p'.

It's easy to implement:

  (defalias 'frame-local-variable-if-set-p 'frame-local-variable-p)

make-variable-frame-local is not like make-variable-buffer-local: it does
not cause `setq' to make the variabke frame-local.  It only means that the
variable setting may be changed on a frame-by-frame basis via
frame-parameters.


        Stefan

Re: frame-local variables weirdness

[Juanma Barranquero]

On 12/9/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> It's easy to implement:
>
>   (defalias 'frame-local-variable-if-set-p 'frame-local-variable-p)

Well, not exactly. frame-local-variable-p would mean that VAR has a
local value. frame-local-variable-if-set-p (perhaps
variable-is-frame-localizable-p is a better name) would mean that
`make-variable-frame-local' has been applied to VAR (so the
Lisp_Buffer_Local_Value has check_frame == 1).

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Richard Stallman]

    I was asking for a way to remove a frame parameter. I don't see any
    remove-frame-parameter, and `modify-frame-parameters' can add and
    modify values, but not remove them, IIUC.

That seems like something we can add now if you really need it.
However, someone needs to check carefully that it interacts
correctly with the local binding mechanism.

Re: frame-local variables weirdness

[Juanma Barranquero]

On 12/10/06, Richard Stallman <rms@gnu.org> wrote:

> That seems like something we can add now if you really need it.

No, I don't need it right now. But I think we should revisit the issue
of frame-local variables post-22.1; as it stands, they are odd and
seem a bit half-cooked. For example, without remove-frame-parameter
there's no easy way to remove a frame-local binding once created.

> However, someone needs to check carefully that it interacts
> correctly with the local binding mechanism.

Yes. That's why I agree it's better to leave the issue for now, even
if there are real (though obscure) bugs.

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Richard Stallman]

I think this should fix your problem.  Does it work in general?

*** data.c	12 Nov 2006 00:16:50 -0500	1.268
--- data.c	10 Dec 2006 23:05:35 -0500	
***************
*** 1207,1215 ****
  	  || buf != XBUFFER (XBUFFER_LOCAL_VALUE (valcontents)->buffer)
  	  || (XBUFFER_LOCAL_VALUE (valcontents)->check_frame
  	      && !EQ (selected_frame, XBUFFER_LOCAL_VALUE (valcontents)->frame))
  	  || (BUFFER_LOCAL_VALUEP (valcontents)
! 	      && EQ (XCAR (current_alist_element),
! 		     current_alist_element)))
  	{
  	  /* The currently loaded binding is not necessarily valid.
  	     We need to unload it, and choose a new binding.  */
--- 1207,1216 ----
  	  || buf != XBUFFER (XBUFFER_LOCAL_VALUE (valcontents)->buffer)
  	  || (XBUFFER_LOCAL_VALUE (valcontents)->check_frame
  	      && !EQ (selected_frame, XBUFFER_LOCAL_VALUE (valcontents)->frame))
+ 	  /* After make-variable-buffer-local, if we haven't got a
+ 	     buffer-local binding in place, we need to make one.  */
  	  || (BUFFER_LOCAL_VALUEP (valcontents)
! 	      && ! XBUFFER_LOCAL_VALUE (valcontents)->found_for_buffer))
  	{
  	  /* The currently loaded binding is not necessarily valid.
  	     We need to unload it, and choose a new binding.  */
***************
*** 1264,1270 ****
  	  XSETCAR (XBUFFER_LOCAL_VALUE (valcontents)->cdr,
  		   tem1);
  
! 	  /* Set `buffer' and `frame' slots for thebinding now loaded.  */
  	  XSETBUFFER (XBUFFER_LOCAL_VALUE (valcontents)->buffer, buf);
  	  XBUFFER_LOCAL_VALUE (valcontents)->frame = selected_frame;
  	}
--- 1265,1271 ----
  	  XSETCAR (XBUFFER_LOCAL_VALUE (valcontents)->cdr,
  		   tem1);
  
! 	  /* Set `buffer' and `frame' slots for the binding now loaded.  */
  	  XSETBUFFER (XBUFFER_LOCAL_VALUE (valcontents)->buffer, buf);
  	  XBUFFER_LOCAL_VALUE (valcontents)->frame = selected_frame;
  	}

Re: frame-local variables weirdness

[Juanma Barranquero]

On 12/11/06, Richard Stallman <rms@gnu.org> wrote:

> I think this should fix your problem.

Yes, thanks.

> Does it work in general?

I don't see any ill effect.

                    /L/e/k/t/u

Re: frame-local variables weirdness

[Juanma Barranquero]

Another bug report from the pre-22.1 past.

This one is an interaction between frame-local and buffer-local variables.

 (defun test (sym bug)
   ;; Default (global) value for the symbol
   (set sym 'default)
   (make-variable-frame-local sym)
   ;; Frame-local value
   (modify-frame-parameters nil (list (cons sym 'frame)))
   (when bug
     ;; Getting the value of sym changes the result
     (symbol-value sym))
   ;; Buffer-local value
   (make-variable-buffer-local sym)
   (set sym 'local)
   ;; Now let's get back the local values
   (list (local-variable-p sym)       ;; should be t
         (symbol-value sym)           ;; should be 'local
         (frame-parameter nil sym)))  ;; should be 'frame

Note that passing t to the BUG argument only changes one thing: that
(symbol-value sym) is run.

  (test 'foo nil) => (t local frame)     ;; correct
  (test 'bar t)   => (nil local local)   ;; incorrect

Richard proposed the attached patch, with fixes the test case but
causes other problems.

             Juanma


Index: src/data.c
===================================================================
RCS file: /sources/emacs/emacs/src/data.c,v
retrieving revision 1.278
diff -u -2 -r1.278 data.c
--- src/data.c	10 Sep 2007 09:41:44 -0000	1.278
+++ src/data.c	11 Oct 2007 09:30:16 -0000
@@ -1238,7 +1238,8 @@
 	  || (XBUFFER_LOCAL_VALUE (valcontents)->check_frame
 	      && !EQ (selected_frame, XBUFFER_LOCAL_VALUE (valcontents)->frame))
+	  /* After make-variable-buffer-local, if we haven't got a
+	     buffer-local binding in place, we need to make one.  */
 	  || (BUFFER_LOCAL_VALUEP (valcontents)
-	      && EQ (XCAR (current_alist_element),
-		     current_alist_element)))
+	      && ! XBUFFER_LOCAL_VALUE (valcontents)->found_for_buffer))
 	{
 	  /* The currently loaded binding is not necessarily valid.

Re: frame-local variables weirdness

[Stefan Monnier]

> Another bug report from the pre-22.1 past.
> This one is an interaction between frame-local and buffer-local variables.

>  (defun test (sym bug)
>    ;; Default (global) value for the symbol
>    (set sym 'default)
>    (make-variable-frame-local sym)
>    ;; Frame-local value
>    (modify-frame-parameters nil (list (cons sym 'frame)))
>    (when bug
>      ;; Getting the value of sym changes the result
>      (symbol-value sym))
>    ;; Buffer-local value
>    (make-variable-buffer-local sym)
>    (set sym 'local)
>    ;; Now let's get back the local values
>    (list (local-variable-p sym)       ;; should be t
>          (symbol-value sym)           ;; should be 'local
>          (frame-parameter nil sym)))  ;; should be 'frame

> Note that passing t to the BUG argument only changes one thing: that
> (symbol-value sym) is run.

>   (test 'foo nil) => (t local frame)     ;; correct
>   (test 'bar t)   => (nil local local)   ;; incorrect

> Richard proposed the attached patch, with fixes the test case but
> causes other problems.

I'd much rather disallow variables that are both buffer-local and frame-local.
What is the use-case?


        Stefan


> Index: src/data.c
> ===================================================================
> RCS file: /sources/emacs/emacs/src/data.c,v
> retrieving revision 1.278
> diff -u -2 -r1.278 data.c
> --- src/data.c	10 Sep 2007 09:41:44 -0000	1.278
> +++ src/data.c	11 Oct 2007 09:30:16 -0000
> @@ -1238,7 +1238,8 @@
>  	  || (XBUFFER_LOCAL_VALUE (valcontents)->check_frame
>  	      && !EQ (selected_frame, XBUFFER_LOCAL_VALUE (valcontents)->frame))
> +	  /* After make-variable-buffer-local, if we haven't got a
> +	     buffer-local binding in place, we need to make one.  */
>  	  || (BUFFER_LOCAL_VALUEP (valcontents)
> -	      && EQ (XCAR (current_alist_element),
> -		     current_alist_element)))
> +	      && ! XBUFFER_LOCAL_VALUE (valcontents)->found_for_buffer))
>  	{
>  	  /* The currently loaded binding is not necessarily valid.


> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/11/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'd much rather disallow variables that are both buffer-local and frame-local.

I think the problem is between frame-local and automatically
buffer-local variables, not just buffer-local ones.

> What is the use-case?

I don't have a use case, and I don't really care one way or the other,
but they have been documented to work for a long time. From
"Frame-Local Variables":

  Buffer-local bindings take precedence over frame-local bindings.
  Thus, consider a variable `foo': if the current buffer has a
  buffer-local binding for `foo', that binding is active; otherwise, if
  the selected frame has a frame-local binding for `foo', that binding is
  active; otherwise, the default binding of `foo' is active.

And they do work, if swap_in_symval_forwarding is not called before
`make-variable-buffer-local'.

How do you propose disallowing them? By fixing the documentation, or
are you saying that setting a variable to be both will throw an error?

             Juanma

Re: frame-local variables weirdness

[Stefan Monnier]

>> I'd much rather disallow variables that are both buffer-local and
>> frame-local.

> I think the problem is between frame-local and automatically
> buffer-local variables, not just buffer-local ones.

I suggest to disallow mixing even with the weaker "buffer-local" flavor.

>> What is the use-case?

> I don't have a use case, and I don't really care one way or the other,
> but they have been documented to work for a long time. From
> "Frame-Local Variables":

>   Buffer-local bindings take precedence over frame-local bindings.
>   Thus, consider a variable `foo': if the current buffer has a
>   buffer-local binding for `foo', that binding is active; otherwise, if
>   the selected frame has a frame-local binding for `foo', that binding is
>   active; otherwise, the default binding of `foo' is active.

> And they do work, if swap_in_symval_forwarding is not called before
> `make-variable-buffer-local'.

> How do you propose disallowing them? By fixing the documentation, or
> are you saying that setting a variable to be both will throw an error?

Signal an error when calling make-local-variable or
make-variable-buffer-local if the variable is already frame-local, and
signal an error in make-variable-frame-local if the variable has already
been made buffer-local.


        Stefan "who'd even go as far as removing the notion of frame-local
                variables: the few uses of them could call frame-parameter
                explicitly just as easily"

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/11/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I suggest to disallow mixing even with the weaker "buffer-local" flavor.

Aha.

> Signal an error when calling make-local-variable or
> make-variable-buffer-local if the variable is already frame-local, and
> signal an error in make-variable-frame-local if the variable has already
> been made buffer-local.

OK.

>         Stefan "who'd even go as far as removing the notion of frame-local
>                 variables: the few uses of them could call frame-parameter
>                 explicitly just as easily"

I think that's probably a good idea, assuming there's no much code out
there which uses them.

             Juanma

Re: frame-local variables weirdness

[Richard Stallman]

    Richard proposed the attached patch, with fixes the test case but
    causes other problems.

What are those other problems?

I could install that patch, so we can discover and fix the
other problems.  But if you have already seen them, let's
debug them first.

    I'd much rather disallow variables that are both buffer-local and frame-local.

We should not cavalierly disallow the use of features in combination
just because there is a bug.  Have you tried to fix those other
problems?  If not, you don't know that it is hard to do so.

Re: frame-local variables weirdness

[Stefan Monnier]

>     I'd much rather disallow variables that are both buffer-local and
>     frame-local.

> We should not cavalierly disallow the use of features in combination
> just because there is a bug.  Have you tried to fix those other
> problems?  If not, you don't know that it is hard to do so.

The interaction of buffer-local and let-bound variables is already tricky
(and has suffered from several bugs over the years).  When we add
frame-local variables to that, it gets yet nastier so I think we should only
support such a feature if there's a clear need for it.  I don't see it.


        Stefan


PS: As a matter of fact, I don't even see a need for frame-local variables
at all: they *are* used currently, but only because they exist.
The potential benefits of using frame-local variables rather than explicitly
using `frame-parameter' are:
- faster access thanks to caching.
- ability to influence the behavior of code which didn't expect the variable
  to be frame-local.
None of the uses I can see benefit from those.  They'd be just as happy
using explicit calls to frame-parameter, which would also simplify the
specbind and Fsymbol_value code (a piece of code that's pretty complex as
it stands), thus streamlining a heavily used code (especially compared to
the rarely used (mis)feature)).

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/12/07, Richard Stallman <rms@gnu.org> wrote:

> What are those other problems?
>
> I could install that patch, so we can discover and fix the
> other problems.  But if you have already seen them, let's
> debug them first.

I tried it a few days ago, and font-locking started acting
erratically: it worked OK in some buffers, partially in other buffers,
and not at all in some.

And, IIRC, when you originally posted the patch it did work for me,
but you reported problems with some of the mode line contents.

>     I'd much rather disallow variables that are both buffer-local and frame-local.
>
> We should not cavalierly disallow the use of features in combination
> just because there is a bug.

That quote is not mine, but Stefan's. I still agree with him, though,
that there's not much gained with frame-local variables, over simple
frame parameters.

             Juanma

Re: frame-local variables weirdness

[Richard Stallman]

    I tried it a few days ago, and font-locking started acting
    erratically: it worked OK in some buffers, partially in other buffers,
    and not at all in some.

Can you reproduce the problem?
Can you figure out, perhaps with breakpoints on the changed code,
which variables are actually affected?

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/13/07, Richard Stallman <rms@gnu.org> wrote:

> Can you reproduce the problem?
> Can you figure out, perhaps with breakpoints on the changed code,
> which variables are actually affected?

I can try.

             Juanma

Re: frame-local variables weirdness

[Richard Stallman]

    PS: As a matter of fact, I don't even see a need for frame-local variables
    at all: they *are* used currently, but only because they exist.

I see that currently they are not used very much.  However, I would
not have added the feature merely because it made sense.  I would only
have done so if it solved a problem.  I would expect there was some
discussion at the time about reasons to add the feature.  Can someone find
that discussion and see what the motive was?

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/14/07, Richard Stallman <rms@gnu.org> wrote:

> I see that currently they are not used very much.

There are four elisp packages that use it currently on the trunk, and
one of them is bs.el, where I added a frame-local variable but I will
surely remove it because I now think it is the wrong fix for the
problem I was solving.

> I would expect there was some
> discussion at the time about reasons to add the feature.  Can someone find
> that discussion and see what the motive was?

That was over nine and a half years ago. The list archives of that
time are not public, so it's a task for someone who was there at that
moment.

             Juanma

Re: frame-local variables weirdness

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     PS: As a matter of fact, I don't even see a need for frame-local variables
>     at all: they *are* used currently, but only because they exist.
>
> I see that currently they are not used very much.  However, I would
> not have added the feature merely because it made sense.  I would
> only have done so if it solved a problem.  I would expect there was
> some discussion at the time about reasons to add the feature.  Can
> someone find that discussion and see what the motive was?

Maybe it is something better achieved by terminal-local variables.
Those were not available at that time.  Just a guess.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: frame-local variables weirdness

[Richard Stallman]

    Maybe it is something better achieved by terminal-local variables.
    Those were not available at that time.  Just a guess.

Terminal-local variables were introduced in 1995,
before frame-local variables.

    > I would expect there was some
    > discussion at the time about reasons to add the feature.  Can someone find
    > that discussion and see what the motive was?

    That was over nine and a half years ago. The list archives of that
    time are not public, so it's a task for someone who was there at that
    moment.

I found the discussion.  I see that someone asked for a feature to
display frame-specific data in the mode line, and I decided this
general feature (with which the job could be done) was cleaner and
simpler than a specific feature which could do only that one job.

Since it isn't very useful, we can take it out if we cannot fix it.
But first let's try to fix it.

Re: frame-local variables weirdness

[Stefan Monnier]

> I found the discussion.  I see that someone asked for a feature to
> display frame-specific data in the mode line, and I decided this
> general feature (with which the job could be done) was cleaner and
> simpler than a specific feature which could do only that one job.

That's a reasonable request, and indeed there are situations where we can
lookup a variable but we cannot call a function which could potentially run
arbitrary code.
Maybe that's enough to keep the feature.

> Since it isn't very useful, we can take it out if we cannot fix it.
> But first let's try to fix it.

But the above request does not mean we need to be able to mix&match
let-bindings, buffer-local, and frame-local variables.  If we disallowed the
buffer-local&frame-local variables, the problem would disappear.  This part
of the language is already complex enough as it stands.


        Stefan

Re: frame-local variables weirdness

[Stephen J. Turnbull]

FWIW, let me remind you that XEmacs has specifiers, which allow rather
flexible mix and match of buffer-local, window-local, and frame-local
properties.
The point is that specifiers have a separate API, no unmarked magic.

This has been a workable compromise for me in those cases where I want
to use it (eg, faces, where specifiers implement flexibility very similar to
Emacs's defface; XEmacs's faces are implemented as a wrapper around
a set of specifiers containing display properties).  There are a few other cases
where I've enjoyed the flexibility (usually controlling behavior of functions
associated with active regions in a display, and in controlling display elements
such as toolbars, tabs, and scrollbars).

David Kastrup may have an informative opinion, since he found XEmacs's glyph
(~ Emacs image) API, uh, "annoying" (and even its author admits it's probably
excessively complex and detailed).  But I'm not sure whether he objects to the
idea of such an API, or merely to XEmacs's implementation in glyphs.

On 10/15/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I found the discussion.  I see that someone asked for a feature to
> > display frame-specific data in the mode line, and I decided this
> > general feature (with which the job could be done) was cleaner and
> > simpler than a specific feature which could do only that one job.
>
> That's a reasonable request, and indeed there are situations where we can
> lookup a variable but we cannot call a function which could potentially run
> arbitrary code.
> Maybe that's enough to keep the feature.
>
> > Since it isn't very useful, we can take it out if we cannot fix it.
> > But first let's try to fix it.
>
> But the above request does not mean we need to be able to mix&match
> let-bindings, buffer-local, and frame-local variables.  If we disallowed the
> buffer-local&frame-local variables, the problem would disappear.  This part
> of the language is already complex enough as it stands.
>
>
>         Stefan
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Re: frame-local variables weirdness

[Stefan Monnier]

> FWIW, let me remind you that XEmacs has specifiers, which allow rather
> flexible mix and match of buffer-local, window-local, and frame-local
> properties.
> The point is that specifiers have a separate API, no unmarked magic.

Yes, I don't know much about specifiers, but indeed, I'd much rather have
something different than just "variables".

E.g. one of the benefits of "frame-local" variables over using
`frame-parameter' is that the user-code doesn't have to know that the data
is local to frames.  So if we later decide to make it terminal-local or
keyboard-local, or window-local the same code will work fine.

So using a new function (get-local-data SYMBOL) we could take care of such
problems.  I suspect that is indeed what XEmacs's "specifiers" are for.


        Stefan

Re: frame-local variables weirdness

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> FWIW, let me remind you that XEmacs has specifiers, which allow
> rather flexible mix and match of buffer-local, window-local, and
> frame-local properties.  The point is that specifiers have a
> separate API, no unmarked magic.

And terminal-local and other stuff.

> This has been a workable compromise for me in those cases where I
> want to use it (eg, faces, where specifiers implement flexibility
> very similar to Emacs's defface; XEmacs's faces are implemented as a
> wrapper around a set of specifiers containing display properties).
> There are a few other cases where I've enjoyed the flexibility
> (usually controlling behavior of functions associated with active
> regions in a display, and in controlling display elements such as
> toolbars, tabs, and scrollbars).
>
> David Kastrup may have an informative opinion, since he found
> XEmacs's glyph (~ Emacs image) API, uh, "annoying" (and even its
> author admits it's probably excessively complex and detailed).  But
> I'm not sure whether he objects to the idea of such an API, or
> merely to XEmacs's implementation in glyphs.

You should use quote marks only around things you actually quote.  I
don't think I called them "annoying".  I certainly was quite annoyed
when I fought with understanding them, but my annoyance was more
directed against their creators.  "incomprehensible" would more likely
be a word I would have used to describe them.

My main problem with specifiers and locales and instantiators was (I
am using the past tense here not because I have by now understood
them, but because I have stopped investing any more time into them)
that they more or less magically change from one form to another, and
it is rather incomprehensible when they do which.  I hear that the
documentation is supposed to be more comprehensive by now, but the
point is that the documentation needs to be (and is) all over the
place.  In contrast, the *-local variables of Emacs need just a single
place in the manual to explain, giving all the _additional_ story
while working like a normal bindings otherwise.  And that is something
which can be used and understood by non-magicians.

It may be considered sort of amusing that the opaque frame/terminal
variable mechanisms are used in the
we-don't-want-opaque-data-structures Emacs and the all-internals-open
specifiers in XEmacs.  But the main problem in my book with the open
XEmacs data structures actually is that there is no reasonably
complete and actually employed API for accessing them.  So one needs
to acquire an understanding of the internal structure of them if one
hopes to understand existing code, and mostly also for writing code of
one's own.

We have in preview-latex code like the following for XEmacs:

;;; [Courtesy Stephen J. Turnbull, with some modifications
;;;  Message-ID: <87el9fglsj.fsf@tleepslib.sk.tsukuba.ac.jp>
;;;  I could not have figured this out for the world]
;;; Hm, there really ought to be a way to get the spec that would be
;;; instantiated in a given domain
  (when preview-tb-icon
    (let ((tb (cdadar (or (specifier-spec-list default-toolbar (current-buffer))
			  (specifier-spec-list default-toolbar 'global)))))
      (unless (member preview-tb-icon tb)
	(set-specifier default-toolbar
		       (append tb (list preview-tb-icon))
		       (current-buffer)))))

There were actually quite a few more ugly examples with regard to
images in earlier times, but I have rewritten the general
functionality/API for the Emacs parts in order to make the worst
XEmacs counterparts be cleaner.

So basically my opinion is that one needs too many complex details in
order to write or understand code involving specifiers.  While the
state of the documentation might have improved to a point where this
information is no longer generally lacking or distributed across a
maze of by-the-way entries, the main problem of the unavoidable
complexity one needs to understand for doing simple tasks remains.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: frame-local variables weirdness

[Stefan Monnier]

>> I found the discussion.  I see that someone asked for a feature to
>> display frame-specific data in the mode line, and I decided this
>> general feature (with which the job could be done) was cleaner and
>> simpler than a specific feature which could do only that one job.

> That's a reasonable request, and indeed there are situations where we can
> lookup a variable but we cannot call a function which could potentially run
> arbitrary code.
> Maybe that's enough to keep the feature.

>> Since it isn't very useful, we can take it out if we cannot fix it.
>> But first let's try to fix it.

> But the above request does not mean we need to be able to mix&match
> let-bindings, buffer-local, and frame-local variables.  If we disallowed the
> buffer-local&frame-local variables, the problem would disappear.  This part
> of the language is already complex enough as it stands.

More specifically, I propose to change the manual to say that we cannot mix
buffer-local and frame-local with a single variable (just like a variable
cannot be both buffer-local and keyboard-local or keyboard-local and
frame-local).

This could come with the attached change in the code, which would fix the
OP's problem by signalling the odd situation earlier.  This would be
installed on the 22 branch, since it's obviously safe.


        Stefan


Index: data.c
===================================================================
RCS file: /sources/emacs/emacs/src/data.c,v
retrieving revision 1.280
diff -u -u -b -r1.280 data.c
--- data.c	16 Oct 2007 15:42:58 -0000	1.280
+++ data.c	17 Oct 2007 23:47:34 -0000
@@ -1521,7 +1521,9 @@
   variable = indirect_variable (variable);
 
   valcontents = SYMBOL_VALUE (variable);
-  if (EQ (variable, Qnil) || EQ (variable, Qt) || KBOARD_OBJFWDP (valcontents))
+  if (XSYMBOL (variable)->constant || KBOARD_OBJFWDP (valcontents)
+      || (BUFFER_LOCAL_VALUEP (valcontents)
+	  && XBUFFER_LOCAL_VALUE (valcontents)->check_frame))
     error ("Symbol %s may not be buffer-local", SDATA (SYMBOL_NAME (variable)));
 
   if (BUFFER_OBJFWDP (valcontents))
@@ -1578,7 +1580,9 @@
   variable = indirect_variable (variable);
 
   valcontents = SYMBOL_VALUE (variable);
-  if (EQ (variable, Qnil) || EQ (variable, Qt) || KBOARD_OBJFWDP (valcontents))
+  if (XSYMBOL (variable)->constant || KBOARD_OBJFWDP (valcontents)
+      || (BUFFER_LOCAL_VALUEP (valcontents)
+	  && XBUFFER_LOCAL_VALUE (valcontents)->check_frame))
     error ("Symbol %s may not be buffer-local", SDATA (SYMBOL_NAME (variable)));
 
   if ((BUFFER_LOCAL_VALUEP (valcontents)
@@ -1733,8 +1737,9 @@
   variable = indirect_variable (variable);
 
   valcontents = SYMBOL_VALUE (variable);
-  if (EQ (variable, Qnil) || EQ (variable, Qt) || KBOARD_OBJFWDP (valcontents)
-      || BUFFER_OBJFWDP (valcontents))
+  if (XSYMBOL (variable)->constant || KBOARD_OBJFWDP (valcontents)
+      || (BUFFER_LOCAL_VALUEP (valcontents)
+	  && !XBUFFER_LOCAL_VALUE (valcontents)->check_frame))
     error ("Symbol %s may not be frame-local", SDATA (SYMBOL_NAME (variable)));
 
   if (BUFFER_LOCAL_VALUEP (valcontents))


Diffs between working revision and workfile end here.

Re: frame-local variables weirdness

[Richard Stallman]

    So using a new function (get-local-data SYMBOL) we could take care of such
    problems.

I don't follow.  What would that function do?

Re: frame-local variables weirdness

[Juanma Barranquero]

> On 10/13/07, Richard Stallman <rms@gnu.org> wrote:
>
> Can you reproduce the problem?
> Can you figure out, perhaps with breakpoints on the changed code,
> which variables are actually affected?

I think someone more experienced in that part of code would have to
debug this. Apparently, with the patch applied the local variables
(keymaps, font-locking, etc.) are bleeding from one buffer to another
and Emacs turns quite difficult to use. A common occurrence in my
tests is the minibuffer having the view-mode-map keymap, and another
good one was the output of describe-function font-locked as it it was
a C buffer (I was visiting data.c at the moment), with `for' and
`default' highlighted :)

But I think the most sensible thing is to apply Stefan's patch and
just forbid mixed buffer-local / frame-local variables.

             Juanma

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/18/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I propose to change the manual to say that we cannot mix
> buffer-local and frame-local with a single variable (just like a variable
> cannot be both buffer-local and keyboard-local or keyboard-local and
> frame-local).

What is a keyboard-local variable?

             Juanma

Re: frame-local variables weirdness

[Stefan Monnier]

>> I propose to change the manual to say that we cannot mix
>> buffer-local and frame-local with a single variable (just like a variable
>> cannot be both buffer-local and keyboard-local or keyboard-local and
>> frame-local).

> What is a keyboard-local variable?

E.g. input-decode-map and local-function-key-map (there's a different one
for each tty and each X11 display to which we're connected).


        Stefan

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/18/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> E.g. input-decode-map and local-function-key-map (there's a different one
> for each tty and each X11 display to which we're connected).

Ah.

"terminal-local" or "display-local" would seem a more accurate description...

Thanks,

             Juanma

Re: frame-local variables weirdness

[Stefan Monnier]

>     So using a new function (get-local-data SYMBOL) we could take care of
>     such problems.

> I don't follow.  What would that function do?

It would behave similarly to `symbol-value' now.  The main difference is
that it wouldn't be implicitly used just by using the SYMBOL because it
wouldn't be considered as a normal variable.  The main implication is that
it wouldn't need to worry about interacting with let-binding and it wouldn't
need to worry about being fast either.

So we can use a much simpler implementation, less buggy, and much more
maintainable and extensible (we could probably easily add any kind of
localness we want: window-local, point-local, time-local, you name it).


        Stefan

Re: frame-local variables weirdness

[Johan Bockgård]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/18/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> E.g. input-decode-map and local-function-key-map (there's a different
>> one for each tty and each X11 display to which we're connected).
>
> Ah.
>
> "terminal-local" or "display-local" would seem a more accurate
> description...

The documentation indeed uses the term "terminal-local".

-- 
Johan Bockgård

Re: frame-local variables weirdness

[Stefan Monnier]

>>> E.g. input-decode-map and local-function-key-map (there's a different
>>> one for each tty and each X11 display to which we're connected).
>> Ah.
>> "terminal-local" or "display-local" would seem a more accurate
>> description...
> The documentation indeed uses the term "terminal-local".

IIUC There's a bit of a mess here introduced by the multi-tty code: if you
run an "emacsclient -t" on /dev/tty1, then suspend it and then run another
one on that same tty, you apparently get two `terminal' objects but a single
keyboard object.

And the terminal objects are somewhat new in multi-tty, so the variables
were really and still are keyboard-local rather than terminal-local (the
C code identifiers clearly always referred to "keyboard" rather than
"terminal").

This said, I'm not actually sure that this is the case: maybe every terminal
has its own keyboard, really.  If not, I believe we should "merge" keyboards
and terminals so as to get rid of this distinction, if at all possible.


        Stefan

Re: frame-local variables weirdness

[Stephen J. Turnbull]

On 10/17/07, David Kastrup <dak@gnu.org> wrote:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:

> > David Kastrup may have an informative opinion, since he found
> > XEmacs's glyph (~ Emacs image) API, uh, "annoying" (and even its
> > author admits it's probably excessively complex and detailed).  But
> > I'm not sure whether he objects to the idea of such an API, or
> > merely to XEmacs's implementation in glyphs.
>
> You should use quote marks only around things you actually quote.  I
> don't think I called them "annoying".

Sorry.  Quotation marks are generally used to mark variant usage of
text, actual quotes being only a special case.  Specifically, the `uh,
"annoying"' form is quite commonly used to imply "the actual words
he used are unrepeatable in polite company".

> specifiers in XEmacs.  But the main problem in my book with the open
> XEmacs data structures actually is that there is no reasonably
> complete and actually employed API for accessing them.  So one needs
> to acquire an understanding of the internal structure of them if one
> hopes to understand existing code, and mostly also for writing code of
> one's own.

Mostly one doesn't.  A buffer-local can be emulated by a specifier by using

(set-specifier buffer-local-variable local-value (current-buffer))

to modify it, and accessing the current buffer's value with

(specifier-instance buffer-local-variable)

I don't recall why the arcane incantation I recommended to you was
needed in your application.  It may be that some version of specifier-instance
would have been satisfactory but I didn't understand your need well enough
to give a more precise answer.

The situation is very similar to working with menus or Emacs-style
keymaps.  There are some conceptually simple tasks that the API
makes unnecessarily hard to do.

Re: frame-local variables weirdness

[Richard Stallman]

    > I don't follow.  What would that function do?

    It would behave similarly to `symbol-value' now.

I understand that, though it is rather general.

      The main difference is
    that it wouldn't be implicitly used just by using the SYMBOL because it
    wouldn't be considered as a normal variable.

What wouldn't be considered as a normal variable?
I am lost here.

It sounds like a step backwards, though.  If we can make the function work
right, we can make it work right for variable values.

Re: frame-local variables weirdness

[Stefan Monnier]

>> I don't follow.  What would that function do?
>     It would behave similarly to `symbol-value' now.

> I understand that, though it is rather general.

>       The main difference is that it wouldn't be implicitly used just by
>     using the SYMBOL because it wouldn't be considered as
>     a normal variable.

> What wouldn't be considered as a normal variable?
> I am lost here.

I'm suggesting we introduce a new concept which we could call "specifier"
or "localizable quasi variable".  We could create them with:

   (defconst new-interprogram-cut-function (make-specifier 'x-select-text))

Now new-interprogram-cut-function is a normal global variable (actually
a constant: we will never `setq' it).  Its value is a "specifier".

Then we get get the value of this specifier with:

   (specifier-value new-interprogram-cut-function)

which would return `x-select-text' because it's currently its only value.
But we could later on change its value on a per-frame basis via maybe:

   (specifier-set new-interprogram-cut-function <some-frame> 'my-fun)

so that the `specifier-value' function returns `my-fun' if the selected
frame is <some-frame> and `x-select-text' otherwise.

> It sounds like a step backwards, though.  If we can make the function work
> right, we can make it work right for variable values.

Again, because this is not a variable, it does not have to be optimized in
the same way and it does not have to interact with let-binding so making it
work correctly is a *lot* easier.

But similarly to variables, we can make sure that `specifier-value' does not
run any elisp code (or even allocate), so it can easily be used in places
where full elisp is undesirable (e.g. the mode-line-format, although
nowadays this accepts full elisp anyway), which was the original motivation
for adding frame-local variables.


        Stefan

Re: frame-local variables weirdness

[Richard Stallman]

I don't like the idea of forbidding the mixing of frame-local and
buffer-local bindings just because we haven't figured out the bug
that makes them not work.

If we understood the problem, and saw that fixing it would be hard,
that could be a valid reason to document it instead of fix it.

Re: frame-local variables weirdness

[Stefan Monnier]

> I don't like the idea of forbidding the mixing of frame-local and
> buffer-local bindings just because we haven't figured out the bug
> that makes them not work.

> If we understood the problem, and saw that fixing it would be hard,
> that could be a valid reason to document it instead of fix it.

It's probably not hard to fix: but it'll take us time and energy for
a feature that nobody has ever used.  And the fix will probably make the
code a bit more complex, require a few more fields in some structure,
etc...

I simply think we should move in the direction of dropping frame-local
variables in favor of something else.  A first step in that direction is to
disallow the more complex aspects of frame-local variables which have never
been used and thus do not deserve to be supported.


        Stefan

Re: frame-local variables weirdness

[Richard Stallman]

    I'm suggesting we introduce a new concept which we could call "specifier"
    or "localizable quasi variable".  We could create them with:

       (defconst new-interprogram-cut-function (make-specifier 'x-select-text))

    Now new-interprogram-cut-function is a normal global variable (actually
    a constant: we will never `setq' it).  Its value is a "specifier".

    Then we get get the value of this specifier with:

       (specifier-value new-interprogram-cut-function)

What we have now, where the variable itself has different bindings in
different contexts, is much cleaner.

Re: frame-local variables weirdness

[Stefan Monnier]

>     I'm suggesting we introduce a new concept which we could call "specifier"
>     or "localizable quasi variable".  We could create them with:

>        (defconst new-interprogram-cut-function
>                  (make-specifier 'x-select-text))

>     Now new-interprogram-cut-function is a normal global variable (actually
>     a constant: we will never `setq' it).  Its value is a "specifier".

>     Then we get get the value of this specifier with:

>        (specifier-value new-interprogram-cut-function)

> What we have now, where the variable itself has different bindings in
> different contexts, is much cleaner.

Could you expand on what you think makes it cleaner?
The above also gives it different bindings in different contexts: the only
difference is that it's not a variable any more, so you can't let-bind it.


        Stefan

Re: frame-local variables weirdness

[Richard Stallman]

    I simply think we should move in the direction of dropping frame-local
    variables in favor of something else.

Maybe we should eliminate them, but I haven't decided yet that
we should eliminate them, and the bug is not a good reason to do so.

Re: frame-local variables weirdness

[Stefan Monnier]

>     I simply think we should move in the direction of dropping frame-local
>     variables in favor of something else.

> Maybe we should eliminate them, but I haven't decided yet that
> we should eliminate them, and the bug is not a good reason to do so.

But what about adding just the checks that make it impossilbe to mix
buffer-localness and frame-localness on the same var?
At least if people use this feature, we'll then know about it.


        Stefan

Re: frame-local variables weirdness

[Richard Stallman]

    Could you expand on what you think makes it cleaner?

The specifier approach requires new functions just to look at or
set the value in the current binding.  It also has the big limitation
that all references to the value must be specially written to
access a specifier.

For these reasons I have decided not to go that way.

Re: frame-local variables weirdness

[Stefan Monnier]

>     Could you expand on what you think makes it cleaner?
> The specifier approach requires new functions just to look at or
> set the value in the current binding.

You mean you have to use `specifier-set' and `specifier-value' instead of
`set' and `symbol-value'?  Well, yes.  Doesn't seem like a big deal to me.

> It also has the big limitation that all references to the value must be
> specially written to access a specifier.

Right, just like right now they're specifically written to access a variable.

> For these reasons I have decided not to go that way.

Too bad,


        Stefan

Re: frame-local variables weirdness

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It also has the big limitation that all references to the value must be
>> specially written to access a specifier.
>
> Right, just like right now they're specifically written to access a variable.

Er, well, isn't the point that that code is in general written to use
variables, so that's _not_ a burden?

The nice thing about these magic variables is that you can make
something frame specific even though the designer of the code didn't
think of that (he just used an ordinary global variable).

If frame(etc)-specific values needed special syntax, either this would
cease to be possible, or else a lot of code would needed to be changed,
a lot of code authors would need to have their habits changed, and a lot
of code would be come a fair bit uglier...

-Miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: frame-local variables weirdness

[Richard Stallman]

    I think someone more experienced in that part of code would have to
    debug this. Apparently, with the patch applied the local variables
    (keymaps, font-locking, etc.) are bleeding from one buffer to another
    and Emacs turns quite difficult to use.

Does this include variables which have no frame-local bindings?
(It sounds like that is what you mean.)

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/21/07, Richard Stallman <rms@gnu.org> wrote:

> Does this include variables which have no frame-local bindings?
> (It sounds like that is what you mean.)

I didn't check, but font-locking variables and mode maps are usually
not frame-local.

             Juanma

Re: frame-local variables weirdness

[Stefan Monnier]

>>> It also has the big limitation that all references to the value must be
>>> specially written to access a specifier.
>> Right, just like right now they're specifically written to access a variable.

> Er, well, isn't the point that that code is in general written to use
> variables, so that's _not_ a burden?

> The nice thing about these magic variables is that you can make
> something frame specific even though the designer of the code didn't
> think of that (he just used an ordinary global variable).

Agreed.  In this sense, specifiers are halfway between frame-local variables
and using frame-parameter: like using frame-parameter they do require the
programmer to expect that the variable is going to be made local to
something, but like frame-local variables they do not require the programmer
to know to what kind of thing it's going to be made local (it can be made
buffer-local, frame-local, window-local, buffer-position-local, ... without
changes to the code).

Maybe a half-way between variables and specifiers would be to declare some
variables as "specifiers": such variables can be read in the usual way (via
symbol-value) and we could probably arange for setq to do something sensible
as well, but let would be ruled out.

Basically, this new proposal is trying to focus on the one issue which
I believe is key: mixing object-local bindings with let-bindings is a source
of pain and bugs.


        Stefan

Re: frame-local variables weirdness

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Agreed.  In this sense, specifiers are halfway between frame-local variables
> and using frame-parameter: like using frame-parameter they do require the
> programmer to expect that the variable is going to be made local to
> something, but like frame-local variables they do not require the programmer
> to know to what kind of thing it's going to be made local (it can be made
> buffer-local, frame-local, window-local, buffer-position-local, ... without
> changes to the code).

That's not "halfway" though.

There's a huge leap from "bog standard global variable" to "special
variable-like-form intended to accessed in a context-dependent way".

I think most programmers will either not be aware of the issue, or will
be reluctant to use such a special form in most cases (with good reason,
if the result is less readable).  In any case, the effect is the same,
that the "availability" of variables for context-specific user
customization of such a system will be much poorer than the current
system.

> Basically, this new proposal is trying to focus on the one issue which
> I believe is key: mixing object-local bindings with let-bindings is a source
> of pain and bugs.

I don't really know the implementation details, so I can't really say.

[Despite the fact that that elisp uses shallow binding, I still seem to
assume deep binding in my mental model of how lisp variables work, and
such mixed usage doesn't seem to be a problem for deep binding... :-]

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: frame-local variables weirdness

[Richard Stallman]

    But what about adding just the checks that make it impossilbe to mix
    buffer-localness and frame-localness on the same var?

As I said before, I don't like the idea of disallowing the mixing of
two features just because there is a bug in it.  Maybe we will have to
disallow that; maybe we should delete frame-local bindings entirely
if they don't seem useful enough to keep.  But first let's try
to debug the bug.

Re: frame-local variables weirdness

[Richard Stallman]

    > The specifier approach requires new functions just to look at or
    > set the value in the current binding.

    You mean you have to use `specifier-set' and `specifier-value' instead of
    `set' and `symbol-value'?  Well, yes.  Doesn't seem like a big deal to me.

It is an added inconvenience.  

    > It also has the big limitation that all references to the value must be
    > specially written to access a specifier.

    Right, just like right now they're specifically written to access a variable.

Accessing a variable is not "specifically written"; it is the normal
thing to do in Emacs.

I hope that this makes my decision clear, but in any case it is a firm
decision.

Re: frame-local variables weirdness

[Stefan Monnier]

>     But what about adding just the checks that make it impossilbe to mix
>     buffer-localness and frame-localness on the same var?

> As I said before, I don't like the idea of disallowing the mixing of
> two features just because there is a bug in it.  Maybe we will have to
> disallow that; maybe we should delete frame-local bindings entirely
> if they don't seem useful enough to keep.  But first let's try
> to debug the bug.

Go for it: I have better things to do than analyse hypothetical bugs.


        Stefan

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/22/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Go for it: I have better things to do than analyse hypothetical bugs.

The bug is real enough, though I agree it's not worth the trouble to
debug it. If frame-local variables have found so little use in nine
years, they should be turned into an ex-feature ASAP.

IMHO, etc.

             Juanma

Re: frame-local variables weirdness

[Stefan Monnier]

>> Go for it: I have better things to do than analyse hypothetical bugs.
> The bug is real enough,

You mean it showed up in real use?


        Stefan

Re: frame-local variables weirdness

[Juanma Barranquero]

On 10/22/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> You mean it showed up in real use?

Well, I wasn't looking for bugs or deliberately constructing
convoluted test cases, I just happened to stumble upon it, but I don't
remember anymore whether that was in a piece of code or just while
trying to understand the implications of frame-local variables. The
example I sent is a convoluted test case, though, designed to
highlight the problem.

Anyway, what I meant is that if we allow variables that can be both
automatically-buffer local and frame-local, and we consider as a
feature that a piece of code "works right" without knowing whether
some variable has been made frame-local or not behind it's back, and
add to it that what triggers the bug is a *read* of the variable's
value at the wrong time... I'd say is a real bug of the "I won't
encounter it in a million years, but the moment I do, I'll have an
interesting time debugging it" variety. YMMV.

All in all, I think in this case we're in violent agreement.

             Juanma

Re: frame-local variables weirdness

[Richard Stallman]

When frame-local variables were first implemented, there was no other
way to put frame-specific data in the mode line.  But now there is,
with :eval.

Since they are hardly used, and the original motive for them 
no longer applies, we may as well delete the feature.

Would you like to do that?

Re: frame-local variables weirdness

[Stefan Monnier]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

> When frame-local variables were first implemented, there was no other
> way to put frame-specific data in the mode line.  But now there is,
> with :eval.

> Since they are hardly used, and the original motive for them 
> no longer applies, we may as well delete the feature.

> Would you like to do that?

Sure.  I currently just marked it obsolete in the 22 branch (with a note in
NEWS), see patch below.  I'll change the pieces of code which make use of
that feature on the trunk.  If anybody wants to help out: feel free.


        Stefan


Index: lisp/subr.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/subr.el,v
retrieving revision 1.554.2.5
diff -u -r1.554.2.5 subr.el
--- lisp/subr.el	23 Aug 2007 18:42:38 -0000	1.554.2.5
+++ lisp/subr.el	23 Oct 2007 20:26:55 -0000
@@ -944,7 +944,7 @@
 (make-obsolete 'focus-frame "it does nothing." "22.1")
 (defalias 'unfocus-frame 'ignore "")
 (make-obsolete 'unfocus-frame "it does nothing." "22.1")
-
+(make-obsolete 'make-variable-frame-local "use a frame-parameter instead" "22.2")
 \f
 ;;;; Obsolescence declarations for variables, and aliases.
 
@@ -988,7 +988,6 @@
 (defalias 'search-backward-regexp (symbol-function 're-search-backward))
 (defalias 'int-to-string 'number-to-string)
 (defalias 'store-match-data 'set-match-data)
-(defalias 'make-variable-frame-localizable 'make-variable-frame-local)
 ;; These are the XEmacs names:
 (defalias 'point-at-eol 'line-end-position)
 (defalias 'point-at-bol 'line-beginning-position)

Re: frame-local variables weirdness

[Richard Stallman]

I will delete them from the Lisp manual.

Re: frame-local variables weirdness

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

> Since they are hardly used, and the original motive for them 
> no longer applies, we may as well delete the feature.

FWIW, I have (ab)used frame local variables for creating a
separate kill ring for each user during collaborative editing
with make-frame-on-display. The result was somewhat quirky,
admittedly.

I will not object very strongly if they disappear, however.

-- 
Johan Bockgård

Re: frame-local variables weirdness

[Chong Yidong]

This bug seems to be the only one left to fix before the release
(apart from the recent display regression described in another
thread).  What's the status?  If it's not at all clear what needs to
be done here, maybe we should postphone it till after 22.2.

We could also check RMS's patch into the trunk and sort out the subtle
bugs in font-lock that it reportedly causes.  Then the changes can be
backported into 22.3.

Re: frame-local variables weirdness

[Stefan Monnier]

> This bug seems to be the only one left to fix before the release
> (apart from the recent display regression described in another
> thread).  What's the status?  If it's not at all clear what needs to
> be done here, maybe we should postphone it till after 22.2.

The status is that it has been deemed a non-bug and frame-local variables
have been declared obsolete (on the 22 branch).


        Stefan

Re: frame-local variables weirdness

[Juanma Barranquero]

On 11/6/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The status is that it has been deemed a non-bug

Yes, for some definition of non-bug. I agree, though, that we shouldn't fix it.

> and frame-local variables
> have been declared obsolete (on the 22 branch).

Which reminds me: wouldn't stil be useful your patch that forbade
making a buffer-local variable frame-local (and the other way around)?

             Juanma