From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#44016: 28.0.50; Add new "gnus-search" search interface to Gnus Date: Mon, 02 Nov 2020 09:24:23 -0500 Message-ID: References: <877drrigg6.fsf@ericabrahamsen.net> <87k0vqsqol.fsf@gnus.org> <87tuuu5fyf.fsf@ericabrahamsen.net> <874km9d4mc.fsf@ericabrahamsen.net> <87o8kgbvv6.fsf@ericabrahamsen.net> <87k0v4bezb.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14776"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 44016@debbugs.gnu.org To: Eric Abrahamsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 02 15:27:25 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kZans-0003fp-Iw for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Nov 2020 15:27:24 +0100 Original-Received: from localhost ([::1]:40928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZanr-00061K-KZ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Nov 2020 09:27:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZala-0004rp-Jn for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 09:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56930) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZala-0006m6-AM for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 09:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZala-0007BH-5Y for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 09:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Nov 2020 14:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44016 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44016-submit@debbugs.gnu.org id=B44016.160432707327553 (code B ref 44016); Mon, 02 Nov 2020 14:25:02 +0000 Original-Received: (at 44016) by debbugs.gnu.org; 2 Nov 2020 14:24:33 +0000 Original-Received: from localhost ([127.0.0.1]:40243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZal7-0007AK-4Y for submit@debbugs.gnu.org; Mon, 02 Nov 2020 09:24:33 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZal5-0007A2-A4 for 44016@debbugs.gnu.org; Mon, 02 Nov 2020 09:24:31 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B38EE10025B; Mon, 2 Nov 2020 09:24:25 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3811E10021B; Mon, 2 Nov 2020 09:24:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1604327064; bh=Z6CwCFa8UkJvmjIPB1iMapHksKeL5stz8ws1lhsiMFU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DKRycBZym4L8P5NHQNGa1+hC6bFMkBLR/184juqBakykzY5vZaOPZmmrf2pm/K1do cS+mbYKg7ZVPuPB4wwHfYzUHgujBOjqIasxzF8iVlGyiGcFFw1jgyuLWhQ6wEBU9Q4 XuFk8hfABhJULQZXJHtFaxWoaw/sBWvT7LrvYJdMFg8tPGdIOwJ/zVuRl8f7Tlj8HJ De/chd5DdOS0MPthweOslXNJ63V9ohiwJRUXUv3JS4JMOyCYyaFGdJ1C/d4i9hntjw pVqMbYRNS6yZrL945csT+zQURVeCo3fUXsBGJS82+nTQNDG2AETU4NemIHutil38uS JHcRFZfTqEUpg== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DFAB61202EE; Mon, 2 Nov 2020 09:24:23 -0500 (EST) In-Reply-To: <87k0v4bezb.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 01 Nov 2020 19:43:36 -0800") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192512 Archived-At: > (the "(consp (cdr (completion-all-completions" bit above definitely > felt like I was holding the tool upside down), It's just another way (more efficient) way to write (< 1 (length (completion-all-completions ...))) so it looks fine from where I stand. > but they're absolutely useful in a programmatic setting. I wonder if > there could be some version of these functions that could be "blessed" > for use in Elisp programs. They're definitely allowed to be used for ELisp programs. They're not 100% pure functions, but not too far off. The main issue I can see for use "internal use" is that their behavior is influenced by the `completion-styles` user-config, which may or may not be what you want. >> (defvar gnus-search-minibuffer-map >> (let ((km (make-sparse-keymap))) >> (set-keymap-parent km minibuffer-local-map) >> (define-key km (kbd "SPC") #'self-insert-command) ;; Isn't this redundant? > > Somewhere I'd gotten the idea that SPC was bound to > `minibuffer-complete-word', I don't know how. I presume you earlier inherited from `minibuffer-local-completion-map` or something like that. > Ah, of course! And if `gnus-search--complete-key-data' is conservative > about when it fires, it leaves the door open for other completion > functions. If by "fires" you mean "returns non-nil", then yes, indeed. > This function could complete "cont" to "contact:", at which > point (for example) an EBDB-specific capf function could take over and > complete names or email addresses to search for. Right. Or it could itself recognize "contact:" and return the bounds of the contact info along with EBDB's completion table (since EBDB's capf presumably doesn't know about the "contact:" syntax). Stefan