From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 19:28:00 +0200 Message-ID: <83sir7yue7.fsf@gnu.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> <87zjlf6tdx.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1393349685 17388 80.91.229.3 (25 Feb 2014 17:34:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 17:34:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 18:34:53 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 1WILu8-00026a-JB for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 18:34:52 +0100 Original-Received: from localhost ([::1]:36282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILu8-0006XH-66 for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 12:34:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILno-0005fW-Gl for emacs-devel@gnu.org; Tue, 25 Feb 2014 12:28:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WILni-0006Ue-Kz for emacs-devel@gnu.org; Tue, 25 Feb 2014 12:28:20 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:52762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILnb-0006Sl-UJ; Tue, 25 Feb 2014 12:28:08 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1K00700B0V7O00@mtaout28.012.net.il>; Tue, 25 Feb 2014 19:28:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1K006QCB7MCQ10@mtaout28.012.net.il>; Tue, 25 Feb 2014 19:28:34 +0200 (IST) In-reply-to: <87zjlf6tdx.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:169866 Archived-At: > From: David Kastrup > Date: Tue, 25 Feb 2014 17:37:14 +0100 > > > Is it certain that we actually need a compiler for that? Did someone > > investigate whether CEDET infrastructure is capable of doing something > > like that? Since, as you point out, a compiler will probably choke on > > syntactically incorrect input, shouldn't we try to look elsewhere? > > After all, we don't need to parse the source completely, only as much > > as needed for completion. > > Nobody can parse C++ reliably. GCC has given up on trying to teach > Bison (aka LALR(1) and then some) how to parse C++ and has implemented > its own hand-written parser. I understand the potential difficulties, but since we only need a relatively small part of parsing, perhaps it's worth trying first? If push comes to shove, what was implemented in GCC can be reimplemented in Emacs Lisp, no? Though I have hard time believing that we will need to go that far. > If you want to be able to reliably follow references to their > _corresponding_ definition, it's almost inavoidable to ask some compiler > for its opinion just what fully qualified function/operator is to be > considered to correspond to the source. I don't understand why, sorry. Are we still talking about smart completion, i.e. displaying candidate expansions of text at or near point? Or are we talking about something else?