From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <50D8002C.5080401@yandex.ru> References: <877gobgpk4.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1356333166 15964 80.91.229.3 (24 Dec 2012 07:12:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Dec 2012 07:12:46 +0000 (UTC) Cc: 13250@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 24 08:13:01 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tn2Dc-0006J2-Q8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Dec 2012 08:13:01 +0100 Original-Received: from localhost ([::1]:56354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tn2DO-00050u-JA for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Dec 2012 02:12:46 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tn2DF-0004yA-3v for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2012 02:12:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tn2DC-0000tq-8d for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2012 02:12:37 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tn2DC-0000ti-4n for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2012 02:12:34 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tn2De-0008WV-IH for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2012 02:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Dec 2012 07:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13250-submit@debbugs.gnu.org id=B13250.135633313032700 (code B ref 13250); Mon, 24 Dec 2012 07:13:02 +0000 Original-Received: (at 13250) by debbugs.gnu.org; 24 Dec 2012 07:12:10 +0000 Original-Received: from localhost ([127.0.0.1]:57504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tn2Co-0008VN-8x for submit@debbugs.gnu.org; Mon, 24 Dec 2012 02:12:10 -0500 Original-Received: from mail-la0-f46.google.com ([209.85.215.46]:46047) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tn2Cm-0008VG-MK for 13250@debbugs.gnu.org; Mon, 24 Dec 2012 02:12:09 -0500 Original-Received: by mail-la0-f46.google.com with SMTP id p5so8166589lag.33 for <13250@debbugs.gnu.org>; Sun, 23 Dec 2012 23:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uCLGgoxhlRI6S5jEd6C9FlB+XPr99HGrlx5pcJMo9Qk=; b=N9nSCBsgBHCEATICHhbFKXmjUIE64ny9u8jvJLnlF0E0LXSSBa8Rn/y6+Aw1eROtoN 5nbCLigd04cVbRBfH7D/pnCfY3YDvm/dlwxcV5MtMBjDIfShlXfalifYxmEzaLWFZTqb PUEoHGYr+dfRzMEmlOVyYq/T2A6MxC6iFvu2ltYkusZHyAAr0CPfEGk6dA+QFfbIesS6 CmFPyBWzedFgYh/ME2C+jD2obcUsTeCsmxs1UkL6cX7naMVNy7l/GbvoOTTRHc8jNAXJ 20W/M+4Et5BWO9wihOF9T05YfxQZLywC9oh5xOnO9A11r8jM9Hxh2EYu896qCwrKrMp4 8mFA== X-Received: by 10.152.114.65 with SMTP id je1mr19658159lab.33.1356333098463; Sun, 23 Dec 2012 23:11:38 -0800 (PST) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPS id t3sm7098235lbl.17.2012.12.23.23.11.35 (version=SSLv3 cipher=OTHER); Sun, 23 Dec 2012 23:11:37 -0800 (PST) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:68982 Archived-At: 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.