|
| From: | Dmitry Gutov |
| Subject: | Re: region-based face-remapping |
| Date: | Fri, 5 Jan 2024 18:25:24 +0200 |
| User-agent: | Mozilla Thunderbird |
On 05/01/2024 16:34, Eli Zaretskii wrote:
Date: Fri, 5 Jan 2024 16:18:28 +0200 From: Dmitry Gutov <dmitry@gutov.dev> Cc: jdtsmith@gmail.com, emacs-devel@gnu.org On 05/01/2024 10:50, Eli Zaretskii wrote:Date: Fri, 5 Jan 2024 05:49:24 +0200 Cc:jdtsmith@gmail.com,emacs-devel@gnu.org From: Dmitry Gutov<dmitry@gutov.dev> On 04/01/2024 09:05, Eli Zaretskii wrote:. one of the subroutines of face_at_buffer_position calls some Lisp hook . that Lisp hook calls code that calls face-font (or some other primitive which takes face-remapping-alist into account)Could you give an example of a Lisp hook which might be called from face_at_buffer_position's subroutines?Why is having a specific example important? Are you saying that there can never be such an example?Yes, it would seem odd to me for face_at_buffer_position to call any hooks.More strange hooks have been added. For example, a face attribute could have a function value, in which case face_at_buffer_position will call into Lisp.
If we added such a feature someday, indeed realize_named_face and others would need to be changed, e.g. by passing the amended value of face-remapping-alist lexically to get_lface_attributes and all its callers (not necessarily the buffer position, though).
But until that happens, it might not be necessary.
But if it did, I would consider whether any of the hooks being called would allow substituting the face with a different one (making it a different way to solve the present feature request).Any face merging looks at face-remapping-alist, so you cannot possibly negate this.
What I was saying is, if an attribute could be a Lisp function, it could be another way to implement what JD is asking for, one that doesn't introduce the 'face-remapping-alist' text/overlay property. But it would be a more complex, less declarative way of doing that. And again, I'm not sure how the overall performance would look with such an addition.
Anyway, the feature seems doable to me, and probably compatible with any addition similar to your example, given enough maintenance effort. I'm not saying we should necessarily have it, though.
| [Prev in Thread] | Current Thread | [Next in Thread] |