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#18643: 25.0.50; elisp--expect-function-p Date: Fri, 10 Oct 2014 07:34:04 +0400 Message-ID: <543753AC.3090604@yandex.ru> References: <86oatmq7lc.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1412912133 32144 80.91.229.3 (10 Oct 2014 03:35:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Oct 2014 03:35:33 +0000 (UTC) Cc: 18643@debbugs.gnu.org To: Stefan Monnier , Leo Liu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 10 05:35: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 1XcQzC-0007wN-US for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Oct 2014 05:35:23 +0200 Original-Received: from localhost ([::1]:46048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcQzC-00039a-Fq for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Oct 2014 23:35:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcQz1-00035T-7a for bug-gnu-emacs@gnu.org; Thu, 09 Oct 2014 23:35:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XcQyt-0005XY-Ol for bug-gnu-emacs@gnu.org; Thu, 09 Oct 2014 23:35:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcQyt-0005Wj-M7 for bug-gnu-emacs@gnu.org; Thu, 09 Oct 2014 23:35:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XcQys-0000he-Lk for bug-gnu-emacs@gnu.org; Thu, 09 Oct 2014 23:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Oct 2014 03:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18643 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18643-submit@debbugs.gnu.org id=B18643.14129120512625 (code B ref 18643); Fri, 10 Oct 2014 03:35:02 +0000 Original-Received: (at 18643) by debbugs.gnu.org; 10 Oct 2014 03:34:11 +0000 Original-Received: from localhost ([127.0.0.1]:39623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XcQy1-0000gG-OT for submit@debbugs.gnu.org; Thu, 09 Oct 2014 23:34:10 -0400 Original-Received: from mail-lb0-f173.google.com ([209.85.217.173]:47802) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XcQxy-0000g5-HY for 18643@debbugs.gnu.org; Thu, 09 Oct 2014 23:34:07 -0400 Original-Received: by mail-lb0-f173.google.com with SMTP id 10so2310887lbg.32 for <18643@debbugs.gnu.org>; Thu, 09 Oct 2014 20:34:05 -0700 (PDT) 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=TWMxufDpqDfRcuqvYs06hKdAC8xQ/5xX26Ytl6LNavo=; b=zSBWoGV4nmrQCp/sv0Iem8GAIGGrcvmgCD9zhJLDHKGJwIQcv4njFRu9QznDakGOy+ /54JDeTVEMXCDNFQkVumr/js3em/CHiLRWa6xbaJlslPZV0+BdxBHgOBKZyKqEBuB9tz q5W/GoQ0DBSLdFMBYbG9cP6tFU5/Rhj8AjLq/r79mCLIex06SJ7682oTddsPvSI9c/TW 4IRiYq9f5M44Su9jZHcJrAq3Dh9yDStHi4/F3wB0KCuMblb6YTIimIoVD646WWCF/cBQ WbqNqxIIIWa+DTeDIleWeir6A5aynIO4pdQ1Yg4FO7BBY/FfdM46BJkkFmKjswgANnMZ m1jg== X-Received: by 10.152.7.145 with SMTP id j17mr1497919laa.67.1412912045454; Thu, 09 Oct 2014 20:34:05 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id d9sm1427831lbp.49.2014.10.09.20.34.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Oct 2014 20:34:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 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:94363 On 10/09/2014 07:27 PM, Stefan Monnier wrote: > I mean, Elisp completion has been context-sensitive "for ever", so the > change is not that it now is, but that it now reacts to the > context differently. It completed against "all available symbols" in way too many situations. And the logic was even simpler before 24.4, where IIRC you adopted some code from company-elisp (and also reimplemented some). > I think this is not right: we should have a elisp--expect-exp-p > which returns non-nil in a context where we know the symbol at point > should be a valid expression (i.e. a variable). Yes, I guess it would make more sense (this function can whitelist certain cases, like function name in a defun, for example). > Not sure how to write > it, tho, but in its absence I think we're better off completing against > "anything" than restricting ourselves to variables. Emacs 25.1 is probably still far away enough for us to get this right. No need to revert useful changes. > BTW, to improve on these behaviors, one approach is to take the > macro-expansion code used in elisp--local-variables and use it > "everywhere". I.e. expand elisp--local-variables so it doesn't just > return the list of local vars, but also returns whether we're inside > a quote, or we're expecting a function, or we're expecting an expression. I'm glad that you think this approach will work. Sounds like then the code will just have to handle a fixed number of forms, which is solvable. Now I just have to wrap my head around `elisp--local-variables'. :)