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
Message #38 received at 77054 <at> debbugs.gnu.org (full text, mbox):
> The "should destructively propertize" part tells me that the function should take care of removing the face properties present in the input string where it doesn't want those fontifications. By contrast, your function calls add-text-properties, which only adds the face properties to a single character, but does nothing with the face properties of the rest of the string.
I read "should destructively propertize" as "mutate the string to
avoid using more memory / efficiency reasons".
While I understand this argument, I could see this behaviour being
problematic in certain situations. For example, a frontend may decide
to do some fontification on top of completion-lazy-hilit-fn (e.g. to
highlight the current candidate differently). While there's an obvious
workaround - the frontend doing their fontification after calling
completion-lazy-hilit-fn - I'm not sure whether it could cause
restrictions in more complex scenarios. Having the completion style
remove all prior fontification sounds a bit extreme for an interface.
For me, it makes more sense to be additive, but I don't know what
Emacs' vision is on this topic.
> can Emacs perform additional fontification (outside the completion frontend and style)?
> I believe the answer is YES
I believe this is problematic. I would like to understand in which
situations does it make sense for Emacs to do fontification outside
the completion frontend and completion style. These are the two main
drivers when completing, and are the ones responsible for the user
interface. Having other parts of the code chime in on fontification,
which is basically user interface, seems to break that division.
`completion--twq-all` is doing fontification. This function doesn't
look like it's part of the completion frontend nor of the completion
style. Why is it doing fontification? Should it be doing
fontification?
> To clarify: this doesn't happen with any of the built-in styles, right?
> To look at this another way - like Joao said, if this happens it might be a problem even without lazy highlighting. Does it occur then?
The reported issue is caused by the fontification applied by
`completion--twq-all` and it happens even without lazy highlighting
(it's just easier to spot when using lazy highlighting because the
expectation is that no fontification will happen prior to it). I would
say that the reason it hasn't been noticed before is that its
behaviour mostly matches the behaviour of the builtin completion
styles, so it won't be noticeable because they're fontifiying the same
characters with the same faces.
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.