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: Tue, 04 Feb 2014 07:37:06 +0200 Message-ID: <52F07C82.4080707@yandex.ru> References: <87d2j8yd12.fsf@yandex.ru> <52EDA4DE.8050904@yandex.ru> <52EDB4B9.9000901@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 1391492297 17039 80.91.229.3 (4 Feb 2014 05:38:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Feb 2014 05:38:17 +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 Tue Feb 04 06:38:23 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 1WAYiE-0001DE-Mh for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Feb 2014 06:38:22 +0100 Original-Received: from localhost ([::1]:50839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAYiE-0002pm-5J for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Feb 2014 00:38:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAYi2-0002p5-8T for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 00:38:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAYhu-0002Jx-OO for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 00:38:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAYhu-0002Jp-Jg for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 00:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WAYhu-0007QE-0S for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 00:38: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: Tue, 04 Feb 2014 05:38: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.139149223428454 (code B ref 16604); Tue, 04 Feb 2014 05:38:01 +0000 Original-Received: (at 16604) by debbugs.gnu.org; 4 Feb 2014 05:37:14 +0000 Original-Received: from localhost ([127.0.0.1]:48645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAYh7-0007Or-FF for submit@debbugs.gnu.org; Tue, 04 Feb 2014 00:37:14 -0500 Original-Received: from mail-ee0-f50.google.com ([74.125.83.50]:52376) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAYh4-0007Oi-IE for 16604@debbugs.gnu.org; Tue, 04 Feb 2014 00:37:11 -0500 Original-Received: by mail-ee0-f50.google.com with SMTP id d17so3997076eek.23 for <16604@debbugs.gnu.org>; Mon, 03 Feb 2014 21:37:09 -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=RNqeH0OLdiSq0Nz4Zlj8j+3d36KacoCtKEgTHriLbVM=; b=TMGRRrjv8Zqk5AdWmHbCADIOevbRGaUuD3YoK205Y1qyZDIppNBzQeCMzsag0z2pg8 WYck1xrcMTIyXLgRfVLBvJ8s82TRybw3jHJwgX+gXbyInRkQ88yP+na72CzL8c2ub+JF t9SuBobuyDxHP4JKig5Uhgp9HhMqjZdcSwQPTc74ihZmiBLRAKXU6xU7JYVOKp/XUU3U 4hM6fqgXUrv56me1erCF0HcyFKZDJkoGW1L18FBy/vT30c28tC9Jzj6oMpEDhW9mMmm2 cGKkTtdprjMcPOUxtP0alqD8iHjNbTIYyFWIVPvLVs2sTbLDz/Fa3KhDp6vlgmwNUe7m MYDA== X-Received: by 10.14.212.71 with SMTP id x47mr215571eeo.98.1391492229760; Mon, 03 Feb 2014 21:37:09 -0800 (PST) Original-Received: from [192.168.10.2] (83-54-31.netrun.cytanet.com.cy. [83.168.54.31]) by mx.google.com with ESMTPSA id y47sm36735834eel.14.2014.02.03.21.37.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 21:37:08 -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:84543 Archived-At: On 02.02.2014 20:24, Stefan Monnier wrote: > The behavior I'm looking for in completion-at-point should probably be > obtained more along the lines of what is done in file-name completion > where completion-ignored-extensions is used before calling > try-completion. I'm not sure I understand. Would there be a variable defining a regexp or glob for variable and function names that will be ignored unless they are the only candidates? > Also, we should try and check that the sub-tables all have "trivial" boundaries, and no quoting. Do we do that at "runtime" (after the lambda has been returned)? And just blow up calls with action `metadata' or `boundaries . ...' with error whenever that's not true? I figured just documenting problematic cases might be enough (like `completion-table-in-turn' does, I suppose it has a similar problem with quoting). > Also, the outer try-completion could end up returning t if one of the inner ones returns the string we're trying to complete. We might be better off always going through "(apply #'append (mapcar #'all-completions ...))", e.g. via completion-table-dynamic. Sounds not very efficient. See the updated patch, does this look right to you? I have a hard time testing it, though. lisp-completion-at-point seems to suggest any symbols that I've ever typed anyway, so there's no way to check that lisp--local-variables-completion-table is even used. === 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-04 05:25:30 +0000 @@ -393,6 +393,36 @@ (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 caveat 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)) + (prelim (try-completion string retvals pred))) + (cond + ((and (stringp prelim) (not (memq t retvals))) prelim) + ((null prelim) (and (memq t retvals) t)) + ;; Here `prelim' is either t, and that means there's at least + ;; one string in `retvals', and all of them are equal to + ;; STRING. + ;; Or `prelim' is a string, but there's a `t' in `retvals', + ;; which means those matches won't all match `prelim'. + (t string)))) + ((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