bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45780: 28.0.50; [PATCH] Face used for affixation function annotation


From: Clemens
Subject: bug#45780: 28.0.50; [PATCH] Face used for affixation function annotations
Date: Mon, 11 Jan 2021 21:07:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

As per the comment above the affected code, the client can specify the face
when prefix and suffix are provided. The prefix is already checked earlier
and what remained was checking the suffix not the prefix.

Shouldn't then this code with font-lock-prepend-text-property
be removed completely?  Since both prefix and suffix are non-nil,
this makes code no-op.

You are right I assumed the suffix can also be nil but looking at the let binding earlier in the code this can't be the case when there is a prefix which is derived from the fact that there is a suffix annotation in the first place :)

There is another thing I would like to bring up in this context: When the
annotations returned by annotation/affixation functions already specify
a face I think it would be nicer if the completion-annotations face
wouldn't be applied generally. In Selectrum we use something like:

(if (text-property-not-all 0 (length str) 'face nil str)
     str
   (propertize str 'face 'completions-annotations))

So you propose to search for the face text-property in the provided string
to decide whether to add the default face in completion--insert-strings?

Yes, the strings of the prefix/suffix.

This gives the client full control over the visual appearance if that is
preferred. Maybe this approach could also make sense to be included in
Emacs?

Do you see any possible backward-compatibility issues with changing this in
Emacs?  For example, when a package like Selectrum puts another face
on the completion string, then it will be displayed instead of the default
completion-annotations face.

We already do this for annotations/affixations in Selectrum but only based on the face of the annotation/affixation itself, the completion string doesn't affect this. I hope this wouldn't have any visual downsides for old code which assumes the faces get merged but I haven't encountered any cases where code tried to apply custom faces to annotations besides the marginalia package. Letting the client control it makes it easier to configure the display as it's hard to predict what will come out of face merging with the face the user has configured as `completion-annotations` face. This new behaviour could also only be applied for affixation functions to avoid any possibly bad effects of existing code.

Thanks for noticing the documentation problem.  Do you think
this fix is sufficient:

Looks good to me, too. Thank you!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]