From: Clemens <clemera@posteo.net>
To: Juri Linkov <juri@linkov.net>
Cc: 45780@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 [thread overview]
Message-ID: <c8b4f5c8-1828-77e4-15f6-160c2bad1e25@posteo.net> (raw)
In-Reply-To: <87ft378gjk.fsf@mail.linkov.net>
>> 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!
next prev parent reply other threads:[~2021-01-11 20:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 12:38 bug#45780: 28.0.50; [PATCH] Face used for affixation function annotations Clemens
2021-01-11 18:38 ` Juri Linkov
2021-01-11 20:07 ` Clemens [this message]
2021-01-12 18:30 ` Juri Linkov
2021-01-13 18:06 ` Clemens
2021-01-14 9:00 ` Juri Linkov
2021-01-14 17:21 ` Clemens
2021-01-14 18:59 ` Juri Linkov
2021-01-14 19:43 ` Clemens
2021-01-25 18:02 ` Juri Linkov
2021-01-30 19:13 ` Juri Linkov
2021-01-31 9:36 ` Clemens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8b4f5c8-1828-77e4-15f6-160c2bad1e25@posteo.net \
--to=clemera@posteo.net \
--cc=45780@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).