Re: face-remapping patch

[David Reitter]

On 28 May 2008, at 08:29, Miles Bader wrote:

> David Reitter <address@hidden> writes:
> > Miles, could you clarify why you are proposing a remapping list  
> > rather
> > than "buffer-local faces"?
>
> How would those work, exactly?
>
> [E.g., what would your proposed interface be?]


Okay, not to criticize your remapping, but just for the sake of  
argument, here's a possible alternative:

A face name refers to the buffer-local face if defined in (current- 
buffer), and to the global one otherwise.

;; causes any modifications to the face face
;; to result in a buffer-local copy of the face
(make-face-buffer-local face)

;; makes a buffer-local copy of the global face face
;; (or defines a new buffer-local one that inherits from the global one)
;; and modifies that
(modify-face (make-local-face face) ...)

;; non-nil if face is local in buffer buffer.
(local-face-p face &optional buffer)

;;Make face no longer have a separate definition in the current buffer.
(kill-local-face face)

When a buffer is killed, so are all its buffer-local faces.

> BTW, one reason for why a remapping alist is so nice is that it
> leverages Emacs' existing infrastructure well.  In particular, the
> user-related parts like face customization are built around global  
> named
> faces (even frame-specific faces are not handled well [at all?] by
> this).


My experience with this infrastructure, using `color-themes' and  
plenty of frames, has been less than stellar.  When switching color  
themes, more and more faces get defined during the session. This slows  
the creation of frames down to the point where it takes 2+ seconds to  
create one.  I had to install a patch in my own version to keep it  
from making frame-specific copies of all global faces for each new  
frame.

Would buffer-local faces lead to better house-keeping? They could be  
thrown away easily with the buffer and reduce the need for global  
faces.