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.
Exactly. Well, they're _encouraged_ to obey it by setting the fn. But they don't have to. Afair many styles don't, likely because that wouldn't bring much speed. Flex does it because by its nature it can match a lot of stuff.
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.
Yup.
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.
All true!
João