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#18265: 24.3.92; lisp-completion-at-point should return nil in comments, unless after ` Date: Sat, 16 Aug 2014 05:02:21 +0400 Message-ID: <53EEAD9D.5010500@yandex.ru> References: <86egwjgtju.fsf@yandex.ru> <53ED7AC0.1050607@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 1408151010 24492 80.91.229.3 (16 Aug 2014 01:03:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Aug 2014 01:03:30 +0000 (UTC) Cc: 18265@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 16 03:03: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 1XISOw-0004Gy-7V for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Aug 2014 03:03:22 +0200 Original-Received: from localhost ([::1]:33850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XISOv-0007F2-SA for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Aug 2014 21:03:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XISOl-0007E2-1p for bug-gnu-emacs@gnu.org; Fri, 15 Aug 2014 21:03:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XISOd-0000iZ-IR for bug-gnu-emacs@gnu.org; Fri, 15 Aug 2014 21:03:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XISOd-0000iQ-DC for bug-gnu-emacs@gnu.org; Fri, 15 Aug 2014 21:03:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XISOc-0000eu-Ic for bug-gnu-emacs@gnu.org; Fri, 15 Aug 2014 21:03: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: Sat, 16 Aug 2014 01:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18265 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18265-submit@debbugs.gnu.org id=B18265.14081509542496 (code B ref 18265); Sat, 16 Aug 2014 01:03:02 +0000 Original-Received: (at 18265) by debbugs.gnu.org; 16 Aug 2014 01:02:34 +0000 Original-Received: from localhost ([127.0.0.1]:44219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XISO9-0000eB-SO for submit@debbugs.gnu.org; Fri, 15 Aug 2014 21:02:34 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:37908) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XISO7-0000ds-6r for 18265@debbugs.gnu.org; Fri, 15 Aug 2014 21:02:31 -0400 Original-Received: by mail-lb0-f169.google.com with SMTP id s7so2493996lbd.0 for <18265@debbugs.gnu.org>; Fri, 15 Aug 2014 18:02:24 -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=tK7ZDOQeGBRrPhP4wzc4wrwCnl19FKIiAfKGDVAh5sQ=; b=fAkc3HFf4wni0x0i8lBClFAFi5Vy4vOF8WaqshFwFdeFuqqhyuZ55uxVkspkI+uJim YYN/tCkBNB0zMnO+W0XCNm1xH6xXZvC1hzYHfTddpTJByM0UVtfEq8n0GfxUnPivOtl3 yrkL5176tzQIUxY6AOfLEDvfN0wPw1pi0b25XqCYcstEcb5TbuM0eaj5WSegDZWQwRWY dRfFeM+30/x7yYCWKdJgABQlZ1IDr7+VwHikH13+bz2bxPypCsuTsI+T7YyzmcTphdG/ C8OYy1KGtj4yEdWHp2xLOhHcwh4I4XTHd3oJINvgQBgTL453SJSE/fiVnpuHir90akVu X/cg== X-Received: by 10.112.118.141 with SMTP id km13mr11742465lbb.37.1408150944803; Fri, 15 Aug 2014 18:02:24 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id k1sm5891294lah.26.2014.08.15.18.02.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Aug 2014 18:02:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.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:92484 Archived-At: On 08/15/2014 04:33 PM, Stefan Monnier wrote: > As it currently stands, there's no question that your original request > is right (the one stated in the "Subject:"), so feel free to fix it. Ok thanks, I will. I've been holding off on committing to trunk until I start using it again, but maybe it's time. > I'm just thinking of how we could also satisfy those who might want to > complete code-like things in comments, without having to resort > to customization. I've suggested one approach (in addition to seeing if there's a backquote before the current prefix): look if the current text is specially indented and separated with empty lines (though this is a very imprecise heurystic). And for the cases when it's not, we can add a new completion function at the end of the default c-a-p-f value, which would work like `company-dabbrev' does. Or like `company-dabbrev-code', in `prog-mode' descendants. `company-capf' would ignore it, for the time being, like it does with `tags-completion-at-point-function' currently. You've called ":exclusive no" a hack yourself before, and :merge-with-rest looks not much different to me, going counter to the c-a-p-f interface. It raises questions, like if `lisp-completion-at-point' would like to be merged with the rest, will it be merged with all of them? Won't the other completion functions get a choice in the matter? What if one of them is smart enough to provide all completions for the current context, by itself? And anyway, it doesn't seem to help with the distinction between manual and idle completion, unless you'd prefer to only activate the :merge-with-rest logic in the case of manual invocation. Which seems orthogonal to the property's purpose.