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

Previous Next

Full log

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.

Previous Next

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