From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#8897: `completion--insert-strings' clobbers user-added text properties Date: Mon, 20 Jun 2011 10:01:22 -0400 Message-ID: References: <8739j5bs01.fsf@gmail.com> <87y60x9b8y.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308578553 17077 80.91.229.12 (20 Jun 2011 14:02:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2011 14:02:33 +0000 (UTC) Cc: 8897@debbugs.gnu.org To: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 16:02:28 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QYf3c-000511-2H for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2011 16:02:28 +0200 Original-Received: from localhost ([::1]:54133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYf3a-0008MG-TW for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2011 10:02:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYf3F-0008Ld-G6 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2011 10:02:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYf3D-0006Yh-FK for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2011 10:02:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56214) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYf3D-0006YU-24 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2011 10:02:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QYf3C-0007D2-0E; Mon, 20 Jun 2011 10:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2011 14:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8897-submit@debbugs.gnu.org id=B8897.130857849627674 (code B ref 8897); Mon, 20 Jun 2011 14:02:01 +0000 Original-Received: (at 8897) by debbugs.gnu.org; 20 Jun 2011 14:01:36 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QYf2l-0007CI-Kg for submit@debbugs.gnu.org; Mon, 20 Jun 2011 10:01:35 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QYf2j-0007C5-CK for 8897@debbugs.gnu.org; Mon, 20 Jun 2011 10:01:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJRS/01FpYrD/2dsb2JhbABTplx4iHO+e4YqBJ1ZhCI X-IronPort-AV: E=Sophos;i="4.65,394,1304308800"; d="scan'208";a="116667414" Original-Received: from 69-165-138-195.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.195]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 20 Jun 2011 10:01:22 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4F00759011; Mon, 20 Jun 2011 10:01:22 -0400 (EDT) In-Reply-To: <87y60x9b8y.fsf@gmail.com> ("=?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?="'s message of "Mon, 20 Jun 2011 10:07:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 20 Jun 2011 10:02:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:47346 Archived-At: >>> In my particular case I define annotations as buttons (which display >>> even more detail about a completion value upon activation), so a visual >>> indication of clickability is very important for me. >> Currently, the completion-list-mode uses the `mouse-face' text-property >> to determine what is a completion item and what i something else (blank >> space, annotation, you name it). So as it stands, any mouse-face you'd >> add to an annotation would confuse completion-list-mode into thinking it >> is a completion item. >> Maybe you could try to use the `category' text-property instead. > Well I do use the `category' property, but the button functions seem to > set up the button face automatically, which is then clobbered by > `completion--insert-strings' (which is the problem). Here's how I set up > an annotation, `n' being the number of a pull request as a string (i.e., > the completion value itself): > #+begin_src elisp > (let ((req (assoc-default n minibuffer-completion-table))) > (concat " " > (propertize (plist-get req :title) > 'fontified t > 'button '(t) > 'category 'default-button > 'help-echo "RET or mouse-2 for details" > 'pr-data req > 'action (lambda (b) (magithub-pull-request-details > (button-get b 'pr-data)))))) > #+end_src I must be missing something: where is a `face' or `mouse-face' property added? The above code should not be affected by your patch, AFAICT. And I don't understand your comment about "but the button functions seem to set up the button face automatically" since I don't see where you call a button function before insertion. > With my patch I haven't noticed any problems you mention -- clicking > or RET on the completion itself selects it, clicking or RET on the > annotation displays further details, the button face is preserved. I guess click&RET work OK because they're locally overridden, but if you run M-x choose-completion while on the button or if you hit `left' or `right' to skip from one completion to the next, you might see some problem (although not with the code quoted above which should not suffer from any of the problems discussed in this thread, AFAICT). Stefan