GNU bug report logs - #45780
28.0.50; [PATCH] Face used for affixation function annotations

Previous Next

Full log

View this message in rfc822 format

From: Clemens <clemera <at> posteo.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: 45780 <at> debbugs.gnu.org
Subject: bug#45780: 28.0.50; [PATCH] Face used for affixation function annotations
Date: Mon, 11 Jan 2021 21:07:57 +0100

>> 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!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.