Re: Specifiers

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>>> Miles, could you clarify why you are proposing a remapping list rather than
>>>> "buffer-local faces"?
>>> 
>>> I think adding "buffer-local faces" directly is no better.  The good
>>> thing about Miles's patch is that it leverages buffer-local variables to
>>> modify faces buffer-locally.  As a result, his patch is pretty small.
>>> 
>>> To improve on this, I think we'd have to move to something more like
>>> XEmacs's specifiers.  But I haven't even seen any proposal for such
>>> a thing yet.
>
>> Proposal: allow a third argument for make-local-variable.
>
> For me, any such proposal which uses variables is simply a
> non-starter.
>
> To undestand why, consider the following, both from the point of view
> of the implementation (where variable access needs to be fast) and of
> the specification of meaningful semantics:
>
> - what should (setq var val) do?
>   currently is magically uses either the global or the current-buffer
>   locus depending on whether the variable is already buffer-local.
>   but if it's buffer-local and frame-local, which setting should
>   be changed?

Of course the one that would get picked when reading the variable.  If
both bindings existed, the buffer-local one would be used with the
priority list I proposed.

> - how does it interact with make-variable-buffer-local?
>   I.e. if a variable is just window-local and you do (setq var val), is
>   it going to be made buffer-local?

"just window-local"?  I think that window-locality should have the
highest priority since one might want to have the same buffer in
different windows.  make-variable-buffer-local essentially registers a
vote for buffer-locality: with the priority list I had proposed, it
would not have an effect when you try setting a window-local variable,
but would create a buffer-local binding shadowing frame/terminal
locality otherwise.

Note that this is mostly theoretic: in practice, one would rarely want
to use different locus types for a single variable.

> - what about `let'?  This one is really fun!

`let' temporarily makes a locus-free binding.  The locality gets
restored at the end of let.  This is not different to the current
interaction of buffer-locality and let.

>   what does
>      (let ((var val)) .. (make-local-variable 'var locus) ..)
>   do?  how 'bout
>     (make-local-variable 'var foo) .. (let ((var val)) .. (setq var foo)?
>   or
>     (make-local-variable 'var foo)..(let ((var 
> val))..(select-other-foo..)var)?

It gets messy.  But this messiness is nothing new:

(info "(elisp) Creating Buffer-Local.")


> BTW, for what it's worth, I have played a tiny bit with something
> similar to what you propose (except that it is separate from
> variables, as you may have guessed ;-).  See sample code below.

> ;;;; Settings
>
> ;; A "setting" is the Emacs equivalent of an XEmacs "specifier".

The problem is that we already have buffer-locality and frame-locality
and terminal-locality.  And the behavior of all those is currently
inconsistent.  The approach I proposed would make them consistent.
Adding something functionally similar to the existing localities but
incompatible is not really helping keeping things simple.  And as long
as not more than one locality was introduced, there would be no speed
impact for the list-based implementation.

It would also be a possibility to allow only a single locality type
which would render the priority question irrelevant.  However, I think
that the usage pattern "basically buffer-local, but overridable in some
window" would be common.

Having something almost, but not quite, entirely unlike XEmacs
specifiers duplicating the same functionality space of the existing
mechanisms -- no, I don't think we want that.

I'll readily admit that specifiers (we have face specs as well) offer
something more than my locality concept: namely uninstantiated
specifications.  But when you instantiate the stuff, namely turn it into
something minted for a specific display or frame, I think that just
making it an appropriately localized variable with a single value will
be likely the most straightforward thing to do.

If it could be done, I think it would encapsulate the complexity into a
small area of the total code, and most programmers would not have to
wrack their brain about it.

-- 
David Kastrup