GNU bug report logs - #13250
24.3.50; Add a way to show pre-highlighted candidates in completions buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13250 in the body.
You can then email your comments to 13250 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50;
	Add a way to show pre-highlighted candidates in completions buffer
Date: Fri, 21 Dec 2012 23:42:19 +0400

[Message part 1 (text/plain, inline)]

When I return the list of candidates from the "completion table"
function, I'd like to be able the specify the base (not user-defined)
highlighting, so that the actual candidate text looks more visible (as
opposed to the annotations) and easy to scan. In my case, the candidates
are method names and the annotations are argument lists, so using
font-lock-function-name-face is natural.

But if I propertize the list with 'font-lock-face properties, both the
"common" part and the "first difference" are still colored black,
because the completion code uses the hardcoded faces for them, one of
which inherits from `default', another from `bold'. Screenshot attached.

Can we change this so that those faces override the face attributes only
if they've been explicitly customized (as opposed to inherited from
`default')?

Is it possible to do that in a backwards-compatible way? With overlays,
maybe?

[completion-faces.png (image/png, attachment)]

Message #8 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50;
	Add a way to show pre-highlighted candidates in completions buffer
Date: Mon, 24 Dec 2012 00:03:47 -0500

> When I return the list of candidates from the "completion table"
> function, I'd like to be able the specify the base (not user-defined)
> highlighting, so that the actual candidate text looks more visible (as
> opposed to the annotations) and easy to scan.  In my case, the candidates
> are method names and the annotations are argument lists, so using
> font-lock-function-name-face is natural.

Adding such faces in the `all-completions' return value is not ideal,
since all-completions can also be called without displaying the result
in *Completions* (e.g. it's used to build the completion in
partial-completion or in substring completion).

That's why we have the annotate-function which adds annotations
separately, only when we know we're going to display the result.

Of course, in your case annotate-function doesn't cut it because it can
only affect the annotation but not the actual completion.  But I'm
mentioning it, because the best long term solution should take it into
account (i.e. extend annotate-function to let you do what you want to
do here).

> But if I propertize the list with 'font-lock-face properties, both the
> "common" part and the "first difference" are still colored black,
> because the completion code uses the hardcoded faces for them, one of
> which inherits from `default', another from `bold'. Screenshot attached.

The problem is that the first-difference and common part will simply
replace the `font-lock-face' property.  We could try and make them
preserve a pre-existing font-lock-face instead.

> Can we change this so that those faces override the face attributes only
> if they've been explicitly customized (as opposed to inherited from
> `default')?

Not sure what you mean here.  If you refer to the ":inherit default" of
completions-common-part, I think it's just a mistake and that face
should simply have a "nil" default (not that it would change much).

> Is it possible to do that in a backwards-compatible way?
> With overlays, maybe?

Overlays can't be added to strings, so they're rather difficult to
use here.

If you really want it badly, you can probably get what you want by
adding `display' properties which replace the completion text with a new
text, identical except you can place any text-property you want on it.


        Stefan

Message #11 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50; Add a way to show pre-highlighted candidates
	in completions buffer
Date: Mon, 24 Dec 2012 11:11:40 +0400

On 24.12.2012 9:03, Stefan Monnier wrote:
>> When I return the list of candidates from the "completion table"
>> function, I'd like to be able the specify the base (not user-defined)
>> highlighting, so that the actual candidate text looks more visible (as
>> opposed to the annotations) and easy to scan.  In my case, the candidates
>> are method names and the annotations are argument lists, so using
>> font-lock-function-name-face is natural.
>
> Adding such faces in the `all-completions' return value is not ideal,
> since all-completions can also be called without displaying the result
> in *Completions* (e.g. it's used to build the completion in
> partial-completion or in substring completion).
>
> That's why we have the annotate-function which adds annotations
> separately, only when we know we're going to display the result.
>
> Of course, in your case annotate-function doesn't cut it because it can
> only affect the annotation but not the actual completion.  But I'm
> mentioning it, because the best long term solution should take it into
> account (i.e. extend annotate-function to let you do what you want to
> do here).

It would have to be a different function and metadata property, no?
I don't think we can change annotation-function to return the candidate 
plus annotation, for example.

>> But if I propertize the list with 'font-lock-face properties, both the
>> "common" part and the "first difference" are still colored black,
>> because the completion code uses the hardcoded faces for them, one of
>> which inherits from `default', another from `bold'. Screenshot attached.
>
> The problem is that the first-difference and common part will simply
> replace the `font-lock-face' property.  We could try and make them
> preserve a pre-existing font-lock-face instead.

So, AFAICT, the proper solution would be to walk the part of the string, 
look at every piece in it that has a different value of 'face, then 
where the value is a symbol, wrap it into a list, and then add the new 
face to the end of the lists. And repeat for the "first difference".
Anything simpler?

>> Can we change this so that those faces override the face attributes only
>> if they've been explicitly customized (as opposed to inherited from
>> `default')?
>
> Not sure what you mean here.  If you refer to the ":inherit default" of
> completions-common-part, I think it's just a mistake and that face
> should simply have a "nil" default (not that it would change much).

Yes, more or less. I was referring to the need to merge the customized 
highlightings onto the already propertized string. The algorithm above 
should work, though.

>> Is it possible to do that in a backwards-compatible way?
>> With overlays, maybe?
>
> Overlays can't be added to strings, so they're rather difficult to
> use here.
>
> If you really want it badly, you can probably get what you want by
> adding `display' properties which replace the completion text with a new
> text, identical except you can place any text-property you want on it.

That's clever, but this way the "first difference" will probably have to 
stay unemphasised. That's not ideal.
I'm not in any particular hurry, maybe I'll implement the long term 
solution.

Message #14 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50;
	Add a way to show pre-highlighted candidates in completions buffer
Date: Sat, 29 Dec 2012 00:29:30 -0500

> It would have to be a different function and metadata property, no?

Could be.

> I don't think we can change annotation-function to return the candidate plus
> annotation, for example.

Currently it can only return a string (which is combined with the
completion into a cons cell), but we could let it return the cons cell
directly.  That wouldn't necessarily help with "annotations before" (and
it wouldn't make sure that the annotations don't actually change
the completions).

> So, AFAICT, the proper solution would be to walk the part of the string,
> look at every piece in it that has a different value of 'face, then where
> the value is a symbol, wrap it into a list, and then add the new face to the
> end of the lists. And repeat for the "first difference".

Yes.  Lars wanted to add a function that does just that, but you can use
font-lock-prepend-text-property in the mean time.


        Stefan

Message #17 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50; Add a way to show pre-highlighted candidates
	in completions buffer
Date: Sat, 12 Jan 2013 07:45:55 +0400

[Message part 1 (text/plain, inline)]

On 29.12.2012 9:29, Stefan Monnier wrote:
>> It would have to be a different function and metadata property, no?
>
> Could be.
>
>> I don't think we can change annotation-function to return the candidate plus
>> annotation, for example.
>
> Currently it can only return a string (which is combined with the
> completion into a cons cell), but we could let it return the cons cell
> directly.  That wouldn't necessarily help with "annotations before" (and
> it wouldn't make sure that the annotations don't actually change
> the completions).

I decided not to do this for now, because it doesn't actually help in my 
case. Or maybe I just haven't encountered a bug that would be caused by 
the additional fontification (as long as I use 'face, not 'font-lock-face).

And the part below works the same, whether the base highlighting was 
added in the completion strings directly, or through the annotation 
function.

Speaking of "annotations before", I don't see how they can be used in 
the current interface. Showing the classes where the methods are defined 
would be good, but lining the candidates up vertically is important for 
visual scan-ability, and the "before strings" can be of different lengths.

>> So, AFAICT, the proper solution would be to walk the part of the string,
>> look at every piece in it that has a different value of 'face, then where
>> the value is a symbol, wrap it into a list, and then add the new face to the
>> end of the lists. And repeat for the "first difference".
>
> Yes.  Lars wanted to add a function that does just that, but you can use
> font-lock-prepend-text-property in the mean time.

Thanks, that was rather easy. I'm attaching a patch that fixes this 
bug's problem for me (letting the fontifications through), so maybe we 
should leave improvements to annotation function for later.

[completions-hl.diff (text/plain, attachment)]

Message #20 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50; Add a way to show pre-highlighted candidates
	in completions buffer
Date: Mon, 04 Mar 2013 11:39:09 +0400

Stefan,

Do you see any problems in the patch I sent for this bug in the previous 
message?

--Dmitry

Message #23 received at 13250 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13250 <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50;
	Add a way to show pre-highlighted candidates in completions buffer
Date: Mon, 04 Mar 2013 09:36:38 -0500

> Do you see any problems in the patch I sent for this bug in the
> previous message?

I'm not sure what impact it might have on speed, but I think the
principle is fine, so go ahead,


        Stefan

Message #28 received at 13250-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13250-done <at> debbugs.gnu.org
Subject: Re: bug#13250: 24.3.50; Add a way to show pre-highlighted candidates
	in completions buffer
Date: Tue, 05 Mar 2013 12:04:20 +0400

On 04.03.2013 18:36, Stefan Monnier wrote:
>> Do you see any problems in the patch I sent for this bug in the
>> previous message?
>
> I'm not sure what impact it might have on speed, but I think the
> principle is fine, so go ahead,

Thanks, installed.

Previous Next

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