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#16604: 24.3.50; False negatives in lisp-completion-at-point Date: Wed, 05 Feb 2014 06:41:14 +0200 Message-ID: <52F1C0EA.9090406@yandex.ru> References: <87d2j8yd12.fsf@yandex.ru> <52EDA4DE.8050904@yandex.ru> <52EDB4B9.9000901@yandex.ru> <52F07C82.4080707@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 1391575331 13712 80.91.229.3 (5 Feb 2014 04:42:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 04:42:11 +0000 (UTC) Cc: 16604@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 05 05:42:19 2014 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 1WAuJW-0000U2-O0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Feb 2014 05:42:18 +0100 Original-Received: from localhost ([::1]:57364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAuJW-0002TF-Bg for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Feb 2014 23:42:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAuJN-0002SF-Id for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 23:42:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAuJG-00008F-TE for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 23:42:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAuJG-00007Y-PL for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 23:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WAuJG-00051m-53 for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 23:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Feb 2014 04:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16604 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16604-submit@debbugs.gnu.org id=B16604.139157528119273 (code B ref 16604); Wed, 05 Feb 2014 04:42:01 +0000 Original-Received: (at 16604) by debbugs.gnu.org; 5 Feb 2014 04:41:21 +0000 Original-Received: from localhost ([127.0.0.1]:50013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAuIb-00050n-3K for submit@debbugs.gnu.org; Tue, 04 Feb 2014 23:41:21 -0500 Original-Received: from mail-ee0-f44.google.com ([74.125.83.44]:37052) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAuIZ-00050e-8c for 16604@debbugs.gnu.org; Tue, 04 Feb 2014 23:41:19 -0500 Original-Received: by mail-ee0-f44.google.com with SMTP id c13so4735110eek.3 for <16604@debbugs.gnu.org>; Tue, 04 Feb 2014 20:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=utTdWImZsnpT7L3J6atgxZfkEQ69EtP4hIOLv+Ueajo=; b=FC3OF3Mo/L6sZ0XunDVU+uMfxnD5pN4qnGupRl9Ke5xVqVIc1D2Yh+bBXkL8yW0u5p Mdx2mJeLO14jw8+xqUlGn5Wpw5V2GX+rglgtmtKrRbmZ/XHLo6NKHbCju4Mh5WS/E2sW 6MHXYJhJOvcU51cKl0R6ETBRf4U+g6ODXbc3ADPkACJV190UccXPyBF8f+sdU+Hn8hsc JuAYBOe94Zde4aNvOxK7GiqCs1xNQlly+8rt6fMOUI4OSLXFAxkKJeyjdkhZL+rWjssR R7d4F6EX3E36LRh3LCWYqTJ0dUoiodv34o1EKMixCBI2Mq+K+IWc0dDuNGzXgTLasRcO A/PA== X-Received: by 10.14.5.11 with SMTP id 11mr19130339eek.57.1391575278342; Tue, 04 Feb 2014 20:41:18 -0800 (PST) Original-Received: from [192.168.10.2] (83-46-90.netrun.cytanet.com.cy. [83.168.46.90]) by mx.google.com with ESMTPSA id g1sm96651953eet.6.2014.02.04.20.41.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 20:41:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:84590 Archived-At: On 04.02.2014 19:54, Stefan Monnier wrote: > I was thinking of a new property which would define a function which > reduces the set of candidates considered for > completion-try-completions. File completion could use it to implement > completion-ignored-extensions and we could use it here to prefer > a local varname. An approach that would work for completion-at-point, but wouldn't touch compan-capf? Sounds promising, though out of scope for this bug. > We don't want to do those checks all the time, so it should probably be > done only once when we combine the two tables (if possible) `completion-metadata' requires both input string and a predicate (I guess, for maximum flexibility of functional completion tables). Pass it an empty string and a nil? And completion boundaries requires suffix as an input. I guess we could see if the table supports boundaries at all by passing an empty string, and if so, raise an error (ignoring the possibility that the table supports only a certain set of suffixes). In that case, we'd be breaking support for merging tables that define boundaries, but are known by the caller to return identical ones. Which could be useful, I guess. > or not at all. Sounds good to me. > Sounds like a bug in lisp-completion-at-point. See http://debbugs.gnu.org/16646. >> + (let ((retvals (mapcar (lambda (table) >> + (try-completion string table pred)) >> + tables)) >> + (prelim (try-completion string retvals pred))) > > try-completion's behavior when passed a list mixing strings and symbols > is not really defined. So this second call to `try-completion' relies > on largely undocumented behavior. Two solutions: either you add > a comment about what behavior you assume, or you change the code to > avoid this problem. > > E.g. change retvals with (delq nil ...) and replace t with `string'. Sure, thanks for catching this. === modified file 'lisp/emacs-lisp/lisp.el' --- lisp/emacs-lisp/lisp.el 2014-01-01 07:43:34 +0000 +++ lisp/emacs-lisp/lisp.el 2014-02-02 01:42:32 +0000 @@ -830,7 +830,7 @@ ;; use it to provide a more specific completion table in some ;; cases. E.g. filter out keywords that are not understood by ;; the macro/function being called. - (list nil (completion-table-in-turn + (list nil (completion-table-merge lisp--local-variables-completion-table obarray) ;Could be anything. :annotation-function === modified file 'lisp/minibuffer.el' --- lisp/minibuffer.el 2014-01-07 23:36:29 +0000 +++ lisp/minibuffer.el 2014-02-05 04:38:11 +0000 @@ -388,11 +388,38 @@ "Create a completion table that tries each table in TABLES in turn." ;; FIXME: the boundaries may come from TABLE1 even when the completion list ;; is returned by TABLE2 (because TABLE1 returned an empty list). + ;; Same potential problem if any of the tables use quoting. (lambda (string pred action) (completion--some (lambda (table) (complete-with-action action table string pred)) tables))) +(defun completion-table-merge (&rest tables) + "Create a completion table that collects completions from all TABLES." + ;; FIXME: same caveats as in `completion-table-in-turn', only harder + ;; to fix. + (lambda (string pred action) + (cond + ((null action) + (let ((retvals (mapcar (lambda (table) + (try-completion string table pred)) + tables))) + (if (member string retvals) + string + (try-completion string + (mapcar (lambda (value) + (if (eq value t) string value)) + (delq nil retvals)) + pred)))) + ((eq action t) + (apply #'append (mapcar (lambda (table) + (all-completions string table pred)) + tables))) + (t + (completion--some (lambda (table) + (complete-with-action action table string pred)) + tables))))) + (defun completion-table-with-quoting (table unquote requote) ;; A difficult part of completion-with-quoting is to map positions in the ;; quoted string to equivalent positions in the unquoted string and