From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: trunk r116285: * lisp/emacs-lisp/lisp.el (lisp-completion-at-point): Symbols don't start Date: Wed, 12 Feb 2014 12:14:57 +0100 Message-ID: <87vbwk60r2.fsf@web.de> References: <87zjm4tl2b.fsf@yandex.ru> <52F99C65.5010007@yandex.ru> <871tz995bl.fsf@web.de> <87ioslaepv.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392203725 23842 80.91.229.3 (12 Feb 2014 11:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2014 11:15:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 12 12:15:33 2014 Return-path: Envelope-to: ged-emacs-devel@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 1WDXmt-0001mN-FH for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 12:15:31 +0100 Original-Received: from localhost ([::1]:38387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDXms-0007QS-W6 for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 06:15:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDXmi-0007QB-E9 for emacs-devel@gnu.org; Wed, 12 Feb 2014 06:15:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDXmc-0000hH-85 for emacs-devel@gnu.org; Wed, 12 Feb 2014 06:15:20 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:55547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDXmc-0000hB-10 for emacs-devel@gnu.org; Wed, 12 Feb 2014 06:15:14 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WDXma-0001f7-9e for emacs-devel@gnu.org; Wed, 12 Feb 2014 12:15:12 +0100 Original-Received: from ip-90-186-155-199.web.vodafone.de ([90.186.155.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Feb 2014 12:15:12 +0100 Original-Received: from michael_heerdegen by ip-90-186-155-199.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Feb 2014 12:15:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-186-155-199.web.vodafone.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:GHgoNwHFEST0T9Ys0gD6oRvcf7s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169550 Archived-At: Dmitry Gutov writes: > Michael Heerdegen writes: > > > Whether a macro evaluates arguments isn't a question of obfuscation. > > Depending on circumstances, it's a necessity. > > When a macro doesn't evaluate an argument, most of the time it's to > introduce a new local var, or define one or several globals. > > IOW, please provide an example of a popular macro that isn't `defadvice' > where this will be a problem. callf, callf2, defsetf. Dunno if callf is popular enough, but I use it very frequently. And `function', as Stefan already mentioned. > Have you tried the patch? When you're inside a quoted structure, any > kinds of meaningful symbols should be offered as completions. I had to fix some wrong line breaks in the patch before applying. But yes, quoted structures work as expected. > > `lisp--form-quoted-p' does only work inside balanced > > parentheses. > > Example? Indeed, it works - my fault, I had only overflown the patch. A situation where your patch doesn't work so well is in quoted structures that actually are evaluated, like in `eval' or `eval-after-load'. Here, completion is like before. But after thinking more about it, situations where your patch is holding back valid completions are quite rare in practice, so I can live with that change. It would be good if the cl-callf2? case would work, however. Thanks, Michael.