On Jan 2, 2024, at 8:00 AM, Eli Zaretskii <eliz@gnu.org> wrote:
From: JD Smith <jdtsmith@gmail.com>
Date: Mon, 1 Jan 2024 19:22:29 -0500
Has there been any discussion of implementing region-based face remapping, perhaps by adding 'face-remap as a property to overlays? This would be very useful for modes in which local syntax highlighting depends on point, now broadly possible thanks to treesitter (think “brighten surrounding semantic unit” or similar).
If you only want to change the appearance around point, you need a much smaller revolution than position-dependent faces, which are something much more general. E.g., position-dependent faces need to change all the face-related APIs to pass a position and a buffer arguments, whereas if it's only "around point", you need nothing like that because the position of point is always known in each buffer.
To make the entire face API position-dependent does seem complex. I presume face calculation first checks if there is a valid 'face-remapping-alist’ and does substitutions. If 'face-remap were a valid (overlay/text) property, that would seem to obviate any deeper API changes: just add this property where remapping is desired. This may relate to the text-property “planes” discussion from a couple years back. Based on that discussion, perhaps targeting only ‘face is not enough. Is there another approach to “selectively enabling/substituting properties by region”, beyond just text-property-search-forward within the region (looking within ‘display properties too)?
To make this concrete, how would people approach the following:
- On point motion, treesitter’s syntax tree is consulted to find an "enclosing semantic context region".
- Within that region, pre-existing faces (or perhaps other properties) get updated to a “highlighted” variant.
- Outdated/prior regions have the highlighted variants removed.
Since you don’t know in advance how large such regions might be, it seems problematic to search and replace all the various faces or other properties.
|