* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
@ 2012-12-21 19:42 Dmitry Gutov
2012-12-24 5:03 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Gutov @ 2012-12-21 19:42 UTC (permalink / raw)
To: 13250
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
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?
[-- Attachment #2: completion buffer --]
[-- Type: image/png, Size: 7524 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2012-12-21 19:42 bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer Dmitry Gutov
@ 2012-12-24 5:03 ` Stefan Monnier
2012-12-24 7:11 ` Dmitry Gutov
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2012-12-24 5:03 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13250
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2012-12-24 5:03 ` Stefan Monnier
@ 2012-12-24 7:11 ` Dmitry Gutov
2012-12-29 5:29 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Gutov @ 2012-12-24 7:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13250
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2012-12-24 7:11 ` Dmitry Gutov
@ 2012-12-29 5:29 ` Stefan Monnier
2013-01-12 3:45 ` Dmitry Gutov
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2012-12-29 5:29 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13250
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2012-12-29 5:29 ` Stefan Monnier
@ 2013-01-12 3:45 ` Dmitry Gutov
2013-03-04 7:39 ` Dmitry Gutov
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Gutov @ 2013-01-12 3:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13250
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]
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.
[-- Attachment #2: completions-hl.diff --]
[-- Type: text/plain, Size: 4019 bytes --]
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog 2013-01-11 23:24:52 +0000
+++ lisp/ChangeLog 2013-01-12 03:37:51 +0000
@@ -1,3 +1,16 @@
+2013-01-12 Dmitry Gutov <gutov@vbx>
+
+ * minibuffer.el (completions-first-difference): State that the
+ face is "added" in the docstring.
+ (completions-common-part): Same. And not inheric from default.
+ (completion-hilit-commonality): Prepend 'completions-common-part
+ and 'completion-first-difference faces to the 'face property,
+ instead of replacing the value.
+ (completion--insert-strings): Same with 'completions-annotations face.
+ (completion-hilit-commonality): Use 'face instead of
+ 'font-lock-face, because it gets priority if the completion
+ strings already have 'face set.
+
2013-01-11 Felix H. Dahlke <fhd@ubercode.de>
* progmodes/js.el: Fix multiline declarations's indentation (bug#8576).
=== modified file 'lisp/minibuffer.el'
--- lisp/minibuffer.el 2013-01-02 16:13:04 +0000
+++ lisp/minibuffer.el 2013-01-12 03:29:23 +0000
@@ -1458,9 +1458,11 @@
'mouse-face 'highlight)
(put-text-property (point) (progn (insert (car str)) (point))
'mouse-face 'highlight)
- (add-text-properties (point) (progn (insert (cadr str)) (point))
- '(mouse-face nil
- face completions-annotations)))
+ (let ((beg (point))
+ (end (progn (insert (cadr str)) (point))))
+ (put-text-property beg end 'mouse-face nil)
+ (font-lock-prepend-text-property beg end 'face
+ 'completions-annotations)))
(cond
((eq completions-format 'vertical)
;; Vertical format
@@ -1487,12 +1489,11 @@
(defface completions-first-difference
'((t (:inherit bold)))
- "Face put on the first uncommon character in completions in *Completions* buffer."
+ "Face added on the first uncommon character in completions in *Completions* buffer."
:group 'completion)
-(defface completions-common-part
- '((t (:inherit default)))
- "Face put on the common prefix substring in completions in *Completions* buffer.
+(defface completions-common-part '((t nil))
+ "Face added on the common prefix substring in completions in *Completions* buffer.
The idea of `completions-common-part' is that you can use it to
make the common parts less visible than normal, so that the rest
of the differing parts is, by contrast, slightly highlighted."
@@ -1513,17 +1514,18 @@
(car (setq elem (cons (copy-sequence (car elem))
(cdr elem))))
(setq elem (copy-sequence elem)))))
- (put-text-property 0
- ;; If completion-boundaries returns incorrect
- ;; values, all-completions may return strings
- ;; that don't contain the prefix.
- (min com-str-len (length str))
- 'font-lock-face 'completions-common-part
- str)
+ (font-lock-prepend-text-property
+ 0
+ ;; If completion-boundaries returns incorrect
+ ;; values, all-completions may return strings
+ ;; that don't contain the prefix.
+ (min com-str-len (length str))
+ 'face 'completions-common-part str)
(if (> (length str) com-str-len)
- (put-text-property com-str-len (1+ com-str-len)
- 'font-lock-face 'completions-first-difference
- str)))
+ (font-lock-prepend-text-property com-str-len (1+ com-str-len)
+ 'face
+ 'completions-first-difference
+ str)))
elem)
completions)
base-size))))
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2013-01-12 3:45 ` Dmitry Gutov
@ 2013-03-04 7:39 ` Dmitry Gutov
2013-03-04 14:36 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Gutov @ 2013-03-04 7:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13250
Stefan,
Do you see any problems in the patch I sent for this bug in the previous
message?
--Dmitry
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2013-03-04 7:39 ` Dmitry Gutov
@ 2013-03-04 14:36 ` Stefan Monnier
2013-03-05 8:04 ` Dmitry Gutov
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-03-04 14:36 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13250
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer
2013-03-04 14:36 ` Stefan Monnier
@ 2013-03-05 8:04 ` Dmitry Gutov
0 siblings, 0 replies; 8+ messages in thread
From: Dmitry Gutov @ 2013-03-05 8:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13250-done
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-03-05 8:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-21 19:42 bug#13250: 24.3.50; Add a way to show pre-highlighted candidates in completions buffer Dmitry Gutov
2012-12-24 5:03 ` Stefan Monnier
2012-12-24 7:11 ` Dmitry Gutov
2012-12-29 5:29 ` Stefan Monnier
2013-01-12 3:45 ` Dmitry Gutov
2013-03-04 7:39 ` Dmitry Gutov
2013-03-04 14:36 ` Stefan Monnier
2013-03-05 8:04 ` Dmitry Gutov
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).