From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.devel Subject: Separating completion candidates and filtering Date: Fri, 18 Aug 2017 23:51:08 -0600 Message-ID: <87a82whzqr.fsf@lylat> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1503121973 16682 195.159.176.226 (19 Aug 2017 05:52:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Aug 2017 05:52:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 19 07:52:48 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1diwgb-0003dH-H9 for ged-emacs-devel@m.gmane.org; Sat, 19 Aug 2017 07:52:41 +0200 Original-Received: from localhost ([::1]:51397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diwgg-0004Zv-Cr for ged-emacs-devel@m.gmane.org; Sat, 19 Aug 2017 01:52:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diwg1-0004ZX-5v for emacs-devel@gnu.org; Sat, 19 Aug 2017 01:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1diwfu-000111-4C for emacs-devel@gnu.org; Sat, 19 Aug 2017 01:52:04 -0400 Original-Received: from mail-it0-x236.google.com ([2607:f8b0:4001:c0b::236]:38176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1diwft-0000zy-TB for emacs-devel@gnu.org; Sat, 19 Aug 2017 01:51:58 -0400 Original-Received: by mail-it0-x236.google.com with SMTP id o72so13888543ita.1 for ; Fri, 18 Aug 2017 22:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:user-agent:mime-version; bh=T6LZUurdwDSLWF8399VQIEkrNQQJmrHrXaBuukEjyWY=; b=Gu2PSm6VhbOIuTuBaiyQcWyI0KkQ5Yyf7Dd8N4778nyisz3HFkqAoUbi73R6Da9z8+ hP1aTuWxfKFDadvGBFqZ22O1ZKW5QG80g1FOS930Arr1uxELqjIu1Y2+I8WPo9PVm8uy umiPDXcyrALHXXpdewbxzeqxrNzUDemU0a5InPhzBp8iD9QGJ3ooK0FXzcXmRp5sGAfp kcmnQ8LtlMhZ7H7PnIXFnN2QVXC0QNty/owS6YVZ/RbuL/ttzIhlyacvR5RMhVh6RkaO aJ+lelwCUgDt+PLV2Ry3LwGoCFDLhL2Rai1GdFedCr6QDQsP+iTvRCVOvmKyAGxOo6C4 Kb8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=T6LZUurdwDSLWF8399VQIEkrNQQJmrHrXaBuukEjyWY=; b=pYADt7D/c3+4qRoUAtSnALbIWDjc07mpo0iDhkJTmWE6J91k3NLze6rJ2z+IuH3DbV +GqiWsKse83A9r9P/6swe9fsQ047MsfgjG3G6WXRoGxbfkcmNzXZ0tLp/4XwBUvURw90 lXnqsMG+j+JPiq+DOuQyXYEqxw6/AD7n+Obk29AGXAkEsv4cbkpQ1lSc9yS4X9xrVMPT P6XNi8mLIvDCsWwnsrkEjr9235a3GXb/mIbsrpK/NLrx6fu5pkrR9GQzFDTrVrqOsWdO YBmjwXREsfqJDxnDdKtNmpkgz6rgUNd7d4iNkrGrnpr+moF4Dlwu717TphTdE06tIYof k9dw== X-Gm-Message-State: AHYfb5hvpKExlLxeRoN7LJHE9mKRpwulS7oaOipV5qWGNQzSubU0w3S2 1ooGvqGlgVncXxCF X-Received: by 10.36.155.136 with SMTP id o130mr413339itd.104.1503121916736; Fri, 18 Aug 2017 22:51:56 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id h82sm1546123itb.1.2017.08.18.22.51.54 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Aug 2017 22:51:55 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217623 Archived-At: --=-=-= Content-Type: text/plain Hello everyone, I'd like to know if there's currently a way for a `completing-read' procedure to instruct to a `minibuffer-completion-table' procedure that it should not do any filtering via, e.g., `completion-table-with-context'. Here is my specific use case: For some reason, I'm looking at making a nicer interface for completing "key=value" pairs in Emacs, which uses AUCTeX's `multi-prompt-key-value'[1]. This nicer interface is mainly for certain 3rd-party completion backends, such as Helm[2] and Ivy[3]. I got the system working more or less how I'd like it (I plan on posting it in the near future), but one issue I'm having is that the procedure `multi-prompt-key-value-collection-fn' uses `completion-table-with-context', which filters the candidates using simple prefix completion (when used with `all-completions'). AFAIU, completion backends such as Helm and Ivy essentially call the `minibuffer-completion-table' mainly to get the list of candidates, and then does the filtering on its own. As it stands, candidates are being filtered by `m-p-k-v-c-f' and by Helm/Ivy's own filtering mechanisms, leading to suboptimal (though not wrong) results. One possible solution to this is adding a new value option for `action' in `complete-with-action' that instructs `completion-table-with-context' to just return the table. I've included a diff that does this[4] below. I'm not very familiar with the contents of minibuffer.el, so I'm sorry if I'm missing something obvious. Footnotes: [1] https://git.savannah.gnu.org/cgit/auctex.git/tree/multi-prompt.el#n188 [2] https://github.com/emacs-helm/helm [3] https://github.com/abo-abo/swiper [4] --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=complete-with-action.diff diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index e5b1029c01..105e7f36e5 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -164,6 +164,7 @@ complete-with-action ((functionp table) (funcall table string pred action)) ((eq (car-safe action) 'boundaries) nil) ((eq action 'metadata) nil) + ((eq action 'identity) table) (t (funcall (cond --=-=-=--