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: Thu, 09 Oct 2014 06:50:55 +0400 Message-ID: <86oatmq7lc.fsf@yandex.ru> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412823155 30100 80.91.229.3 (9 Oct 2014 02:52:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Oct 2014 02:52:35 +0000 (UTC) Cc: 18643@debbugs.gnu.org To: Leo Liu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 09 04:52:27 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 1Xc3q1-0002KX-Rv for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Oct 2014 04:52:22 +0200 Original-Received: from localhost ([::1]:39557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc3q1-0007Uc-H6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2014 22:52:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc3pq-0007UU-BH for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2014 22:52:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xc3pi-00007u-QW for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2014 22:52:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc3pi-00007k-MC for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2014 22:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xc3ph-000429-S8 for bug-gnu-emacs@gnu.org; Wed, 08 Oct 2014 22:52: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: Thu, 09 Oct 2014 02:52:01 +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.141282306215421 (code B ref 18643); Thu, 09 Oct 2014 02:52:01 +0000 Original-Received: (at 18643) by debbugs.gnu.org; 9 Oct 2014 02:51:02 +0000 Original-Received: from localhost ([127.0.0.1]:38369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xc3oj-00040Q-7d for submit@debbugs.gnu.org; Wed, 08 Oct 2014 22:51:02 -0400 Original-Received: from mail-la0-f52.google.com ([209.85.215.52]:61003) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xc3of-00040C-H9 for 18643@debbugs.gnu.org; Wed, 08 Oct 2014 22:50:58 -0400 Original-Received: by mail-la0-f52.google.com with SMTP id hz20so296216lab.39 for <18643@debbugs.gnu.org>; Wed, 08 Oct 2014 19:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=2WJHVJtXN6FmsgH3P99dI44c0jNl4mAZB1L02KuaR/M=; b=nwzJA57a5qlmwpwHI5LSorSP/eY7fOnY/k/63/HgPjU1GKDS5ScOx/mC9DtBlk4938 Mmw6js2H7Xtwji7bY7BhQNNeqbPva7d4y5OSMu0ZjfGoQ0AhYiB3s63qMUuF3OSFAson npwZPsK47065iDD5Pggm4jp+AhXBF2qh8VmmedB6KULx5DEcjYC1oSWGZBJsJejHQc9S bLq5O8tncoyBzSOdEqTg+3sREloyxUeSbHDc5EbwvTFYKnqBsWg+5DBQ3RiB9FA6mCbE 3XPywaBX0GSH/TccLokF4IkxeXmgPG84eT+nyN+cDhiZ237YPk7RcsnNNdc6V5DQ6Mr/ IzsA== X-Received: by 10.112.17.132 with SMTP id o4mr8480238lbd.52.1412823056367; Wed, 08 Oct 2014 19:50:56 -0700 (PDT) Original-Received: from axl ([178.252.98.87]) by mx.google.com with ESMTPSA id iq1sm570894lac.9.2014.10.08.19.50.55 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 08 Oct 2014 19:50:55 -0700 (PDT) In-Reply-To: (Leo Liu's message of "Mon, 06 Oct 2014 13:13:05 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux) 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:94319 Hi Leo, Leo Liu writes: > emacs should only constrain itself to function completion when > absolutely sure. How can we make sure? I think macro-expansion could help in some cases, but implementing that approach is a bit beyond me. > It is not a big deal if function names creep into variable completion or > vice versa. Often it is handy to complete to an existing symbol and then > edit it into something else. IME, context-sensitive completion is useful, and people like it. Narrowing down the list of possible completions is often quite useful, especially when it can turn 2-3 completions into just one, which can be inserted with one key. I think we can sacrifice completion in certain rare cases to retain this advantage in general. > For example, one might need to create a variable name based on a > function name. I'm pretty sure writing a new variable definition is a much less frequent operation than referring to a variable in a function, or writing a function call. And code completion is most useful when one is referring to existing variables and functions. > There are a few places where I expect to have a completion based on my > past experience but fail now. For example, in (pred ...) pattern of > pcase. Other failures, (let (|)) and (let ((|))) where | is point. If you care to enumerate the main problem cases, and how they fail, it shouldn't be too hard to add support for them. But of course, we'll continue to have false negatives in some cases, like third-party macros. > I have experienced annoyances here and there and I think the fundamental > solution is not to second guess but complete liberally as we did before. That suggestions sounds like giving up to me. For what you're describing, you might like dabbrev-style completion, or a simple function that looks up symbols in obarray. If you're not using company-mode, maybe try porting company-dabbrev-code to completion-at-point-functions, and use that. I haven't spent a lot of time using the current trunk, but the recent changes replicate the logic from company-elisp, and I quite liked it (before it was deprecated in favor of company-capf). I haven't seen many complaints about function-variable separation there. That backend does have a `company-elisp-detect-function-context' user option (so that's another solution for the issue discussed here), but it doesn't seem to be used much (if at all), judging by the publicly available configurations. -- Dmitry