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#16604: 24.3.50; False negatives in lisp-completion-at-point Date: Tue, 04 Feb 2014 12:54:34 -0500 Message-ID: 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 X-Trace: ger.gmane.org 1391539298 32359 80.91.229.3 (4 Feb 2014 18:41:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Feb 2014 18:41:38 +0000 (UTC) Cc: 16604@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 04 19:41:44 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 1WAkwJ-00007w-8s for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Feb 2014 19:41:43 +0100 Original-Received: from localhost ([::1]:54096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAkwI-0000ys-UH for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Feb 2014 13:41:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAkw7-0000rC-E1 for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 13:41:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAkvz-0004Oi-79 for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 13:41:31 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAkE7-000215-7F for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 12:56:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WAkE6-0001Km-HK for bug-gnu-emacs@gnu.org; Tue, 04 Feb 2014 12:56: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: Tue, 04 Feb 2014 17:56:02 +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.13915365085054 (code B ref 16604); Tue, 04 Feb 2014 17:56:02 +0000 Original-Received: (at 16604) by debbugs.gnu.org; 4 Feb 2014 17:55:08 +0000 Original-Received: from localhost ([127.0.0.1]:49689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAkDC-0001JP-EH for submit@debbugs.gnu.org; Tue, 04 Feb 2014 12:55:07 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:58925) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WAkD6-0001Ix-I5 for 16604@debbugs.gnu.org; Tue, 04 Feb 2014 12:55:01 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 4F37384E49; Tue, 4 Feb 2014 12:54:59 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 368331E5913; Tue, 4 Feb 2014 12:54:35 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 0777BB40FE; Tue, 4 Feb 2014 12:54:34 -0500 (EST) In-Reply-To: <52F07C82.4080707@yandex.ru> (Dmitry Gutov's message of "Tue, 04 Feb 2014 07:37:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:84559 Archived-At: > 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? 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. >> 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? 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) or not at all. > I figured just documenting problematic cases might be enough (like > completion-table-in-turn' does, I suppose it has a similar problem with > quoting). Right. > Sounds not very efficient. Probably lost in the noise. > See the updated patch, does this look right to you? Could be, see below. > 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. Sounds like a bug in lisp-completion-at-point. > + (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'. Stefan