emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding new variable for face-list in internal-make-lisp-face.


From: Eli Zaretskii
Subject: Re: Adding new variable for face-list in internal-make-lisp-face.
Date: Sat, 04 Nov 2017 10:13:33 +0200

> Date:  Fri, 03 Nov 2017 23:56:53 -0700
> From:  Keith David Bershatsky <address@hidden>
> Cc:  address@hidden
> 
> It has been a long day, but I wanted to give you an update on my findings 
> thus far this evening before turning off the computer.
> 
> There is no good reason (that I can see) why the Lisp function glyph-face 
> should be using face-list.  Instead, the Lisp function glyph-face should be 
> mapping through face-new-frame-defaults and comparing the car of each element 
> to the face-id.  Using that new method of just checking the car of 
> face-new-frame-defaults works sufficiently quickly in C (as far as I can 
> tell).  So the need for speed appears to be resolved in my early tests 
> tonight.
> 
> The problem with an invalid lisp object happens after manually calling 
> eval-defun on a defface when the background has been changed by the user.  In 
> that situation, the face-id changes.  However, the buffer-display-table does 
> NOT update to reflect the new face id.  In my situation, the original face 
> had an id of 121.  After changing the background color (with eval-defun on a 
> defface), the face id changed from 121 to 1196.

Face IDs are ephemeral, because Emacs frees all faces and realizes
them anew from time to time, when it thinks the previous definitions
might be invalid.  E.g., when the attributes of the default face
change, all the faces need to be recomputed, because many of them
inherit from the default face.

So if you use the face ID, you need to recompute it each time you need
it.  You cannot compute it once and then reuse the same value, because
sooner or later it will become invalid.

> So we cannot rely on the buffer-display-table cons cell with the glyph code 
> for a tab face after calling eval-defun, because it still has the number 121.

See next_element_from_display_vector for how the faces of glyphs from
a display table are used to display those glyphs.  And because of what
I said above, once you have the face ID, you need to use lookup_*_face
functions to get the face corresponding to that ID.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]