Re: face-remapping patch

[David Kastrup <dak@gnu.org>]

Richard M Stallman <rms@gnu.org> writes:

> Your local variable feature is quite clean.

If features could be implemented just by writing DOC strings, we'd
likely have a lot of clean features.

The documentation might be clean, but that does not necessarily make the
implementation nice.

>     (local-variable-p VARIABLE &optional LOCUS)
>
>     Non-nil if VARIABLE has a local binding in locus LOCUS (see make-variable).
>     BUFFER defaults to the current buffer.
>
> If LOCUS is nil, this should mean "Is any kind of local binding now in
> effect?"

Well, that would be backwards incompatible: I actually stole half of the
descriptions from existing functions and DOC strings.

I was just describing an interface that I would be able to understand.
That does not mean that it corresponds with a simple or elegant or
efficient or flexible implementation.

If a variable has an associated vector of locuses, the elements of which
would be something like

[last-checked-selected-window
 last-checked-current-buffer
 last-checked-selected-frame
 last-checked-selected-terminal]

Where "nil" means "no local value of that kind for this variable", then
when accessing a variable, one would run through that array, and would
for the first non-nil entry not corresponding to the current locus
update the current value from some hash structure indexed via
(locus . symbol).

A list instead of a vector would be conceivable, too, (and would make
the default of variables without any local binding faster) but one would
have to think about how to order and prioritize it properly, then.

-- 
David Kastrup