Re: frame-local variables weirdness

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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"