Re: face-remapping patch

[David Kastrup]

Sorry, C-c C-c is just too close to C-x C-x.  This posting was not
finished.

David Kastrup <address@hidden> writes:

> 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.
>
> (make-local-variable VARIABLE &optional locus)
>
> Make VARIABLE have a separate value in the given locus (defaulting to
> the current buffer).
>
> A locus can be a buffer, a frame, a terminal, a window.  When there is
> more than one locus for which a variable may be local, the value is used
> from the first locus in the list window - buffer - frame - terminal.
>
> (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.
>
> variable-binding-locus is a built-in function in `C source code'.
>
> (variable-binding-locus VARIABLE)
>
> Return a value indicating where VARIABLE's current binding comes from.
> If the current binding is buffer-local, the value is the current buffer.
> If the current binding is frame-local, the value is the selected frame.
> If the current binding is global (the default), the value is nil.

That one actually already exists.

For the following, s/buffer/locus/g:

    buffer-local-value is a built-in function in `C source code'.

    (buffer-local-value VARIABLE BUFFER)

    Return the value of VARIABLE in BUFFER.
    If VARIABLE does not have a buffer-local binding in BUFFER, the value
    is the default binding of the variable.

Bing.  A simple API, easy to understand, easy to use.  And
_transparent_.

Now XEmacs specifiers offer something more: you can specify local values
for _classes_ of display, like B&W, or reduced color or so.  We have
something like that for faces.

However, I don't think the price for the generality of specifiers is
worth the complexity in the particular implementation and documentation
state of XEmacs.  I did not understand them after trying for a
considerable amount of time, and I am arrogant enough to consider
something which I feel unable to understand as being off the complexity
bell curve for reliable engineering.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum