From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 20:50:11 +0100 Message-ID: <8761o3dlak.fsf@wanadoo.es> References: <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> <83sir7yue7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393357840 24480 80.91.229.3 (25 Feb 2014 19:50:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 19:50:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 20:50:48 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 1WIO1f-0002mq-4d for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 20:50:47 +0100 Original-Received: from localhost ([::1]:36819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIO1e-0006CK-Pn for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 14:50:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIO1R-00065A-3w for emacs-devel@gnu.org; Tue, 25 Feb 2014 14:50:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIO1K-0006pp-Nr for emacs-devel@gnu.org; Tue, 25 Feb 2014 14:50:32 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:56233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIO1K-0006pd-HC for emacs-devel@gnu.org; Tue, 25 Feb 2014 14:50:26 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIO1H-00017p-Uq for emacs-devel@gnu.org; Tue, 25 Feb 2014 20:50:23 +0100 Original-Received: from 19.red-83-39-162.dynamicip.rima-tde.net ([83.39.162.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 20:50:23 +0100 Original-Received: from ofv by 19.red-83-39-162.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 20:50:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 19.red-83-39-162.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:084KhBJQTffcSmgNiZjBKg8jYpw= 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:169870 Archived-At: Eli Zaretskii writes: >> 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, Why do we need a small part of parsing? For implementing C++ smart completion on a reliable way, you need semantic analysis. Furthermore, people here are talking too much about completion, but there are other features that require whole-program semantic analysis and hence are out of reach of the approaches mentioned here based on gcc spitting not-quite-comprehensive information. > perhaps it's worth trying first? If > push comes to shove, what was implemented in GCC can be reimplemented > in Emacs Lisp, no? Right now the available systems for smart code completion are annoyingly slow. They are implemented on C/C++. It is reasonable to expect from a Elisp-based solution to be unbearably slow, not to mention the complexity. Why reinvent the wheel? > 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? Dunno about David, but I say "yes", for smart completion you need way more than quick & dirty parsing.