GNU bug report logs -
#77054
Completion highlighting applied outside completion-lazy-hilit-fn
Previous Next
Reported by: João Guerra <joca.bt <at> gmail.com>
Date: Sun, 16 Mar 2025 15:28:01 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.