* 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).