Subject: bug#77054: Completion highlighting applied outside completion-lazy-hilit-fn

From: Dmitry Gutov <[email-masked]>
Date: Thu, 20 Mar 2025 19:26:55 +0200

On 20/03/2025 19:11, João Távora wrote:
> The function may do this and it's passed a fresh string to destroy at 
> will I think, but it may not matter if later parts of the machinery add 
> these properties. It could come from the table's sorting for example. 
> There's little the style can do about that.
> 
> Furthermore, as I've been trying to explain, lazy highlighting as I 
> implemented is completely orthogonal. It's just a mechanism to allow 
> front ends to delay fontification to the last possible moment when they 
> actually display stuff to the user. Styles are not supposed to set it to 
> anything that fontifies differently/specially because styles don't know 
> in general what frontend is driving them. IOW, whatever problem the OP 
> is experiencing would likely be there if lazy highlighting were turned 
> off (by the frontend or the style, or both).

Styles are indeed not supposed to alter it - they're supposed to obey it 
instead.

But completion-lazy-hilit does have something to do with not altering 
the original string: that's the whole definition of 
completion-lazy-hilit: if on, do copy-sequence first.

Completion tables might alter the strings inside their sorting, but they 
own those string so that seems fine. Completion style's sorting should 
avoid that. This was a large part of the discussion we had at the time, 
and one result is that the sorter inside 
completion--flex-adjust-metadata does not alter the strings.