From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 17:37:14 +0100 Organization: Organization?!? Message-ID: <87zjlf6tdx.fsf@fencepost.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393346268 5129 80.91.229.3 (25 Feb 2014 16:37:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 16:37:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 17:37:55 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 1WIL0v-000599-DF for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 17:37:49 +0100 Original-Received: from localhost ([::1]:35793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIL0v-0002fq-1n for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 11:37:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIL0l-0002XT-Qe for emacs-devel@gnu.org; Tue, 25 Feb 2014 11:37:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIL0d-00053z-HB for emacs-devel@gnu.org; Tue, 25 Feb 2014 11:37:39 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIL0d-00053s-Bm for emacs-devel@gnu.org; Tue, 25 Feb 2014 11:37:31 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIL0Z-0003SP-4u for emacs-devel@gnu.org; Tue, 25 Feb 2014 17:37:27 +0100 Original-Received: from x2f51cea.dyn.telefonica.de ([2.245.28.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 17:37:27 +0100 Original-Received: from dak by x2f51cea.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 17:37:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f51cea.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:MFiVld3oCjhI/RI2cARaMqTsveE= 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:169862 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? 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. Existing C++ compilers went through years of bugfixing until they got things standard-compliant most of the time. Since C++ has overloaded functions and operators and a rather complex type conversion lattice, figuring out just _which_ fully qualified function or operator will get called in a large composite expression is quite a hard feat. 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. Things like indentation and syntax highlighting are somewhat more amicable since overloading resolution does not influence things like expression priorities. -- David Kastrup