From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 15:15:44 -0600 Message-ID: <85d2ia51xb.fsf@stephe-leake.org> References: <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <8338j717oe.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393362956 21719 80.91.229.3 (25 Feb 2014 21:15:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 21:15:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 22:16:04 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 1WIPM9-0005C3-LB for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 22:16:01 +0100 Original-Received: from localhost ([::1]:37119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPM9-00042C-5x for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 16:16:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPM0-000415-RT for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:15:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIPLv-0001WI-0m for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:15:52 -0500 Original-Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.225]:15213 helo=cdptpa-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPLu-0001WC-TM for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:15:46 -0500 Original-Received: from [75.87.81.6] ([75.87.81.6:50530] helo=TAKVER) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 2B/5E-10928-1080D035; Tue, 25 Feb 2014 21:15:46 +0000 In-Reply-To: <8338j717oe.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Feb 2014 18:25:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.166.225 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:169874 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Tue, 25 Feb 2014 10:41:42 +0100 >> >> The "annotated syntax tree" question would become more relevant for >> things like sourcecode highlighting. But in the interest of usefully >> fast feedback when editing, it would likely make more sense to let Emacs >> do the highlighting with local rules on its own and only converse with >> GCC when it becomes necessary to resolve ambiguities (like >> declaration/expression distinctions): GCC can only make helpful >> suggestions regarding the last time the source code was syntactically >> correct, so most of the time Emacs will need to go ahead with _some_ >> idea anyway. > > Is it certain that we actually need a compiler for that? Did someone > investigate whether CEDET infrastructure is capable of doing something > like that? I recently rewrote the Ada indentation engine, and tried to use the CEDET infrastructure. It was not adequate, so I ended up writing a full parser (it is similar to but more powerful than the CEDET lexer/parser). Even so, I don't use that for completion, especially when looking for the parameters of functions. As I pointed out in another email, AdaCore provides 'gcc -fdump-xref', which dumps all the information needed for that, and a tool 'gnatinspect' that interfaces nicely with Emacs to retrieve it. I have not fully implemented completion in Emacs using that, but AdaCore has in their editor GPS, so I know it's possible :). > Since, as you point out, a compiler will probably choke on > syntactically incorrect input, shouldn't we try to look elsewhere? The current hippie-expand mechanisms offer completion on identifiers in current buffers; beyond that, I don't see any solution other than to rely on compiled code for completion, especially of parameters of functions. > After all, we don't need to parse the source completely, only as much > as needed for completion. That's the same thing, as far as I can tell. You need even less info for indentation, but I ended up needing a full file parse for that. Actually, only a full "compilation unit" parse; in Ada that is normally a full file. In C++ it would be a class or function definition. Still a complete language parser. -- -- Stephe