Re: frame-local variables weirdness

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

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