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 23:12:07 +0200 Message-ID: <83bnxuzyl4.fsf@gnu.org> 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> <8761o3dlak.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1393362742 19307 80.91.229.3 (25 Feb 2014 21:12:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 21:12:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 22:12:30 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 1WIPIi-0006cx-Oi for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 22:12:28 +0100 Original-Received: from localhost ([::1]:37082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPIi-0002NJ-5r for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 16:12:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPIa-0002NC-PY for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:12:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIPIV-0000I7-F1 for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:12:20 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPIV-0000I2-6X for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:12:15 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N1K00L00L9A5T00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 25 Feb 2014 23:12:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1K00KTQLKCVR60@a-mtaout20.012.net.il>; Tue, 25 Feb 2014 23:12:12 +0200 (IST) In-reply-to: <8761o3dlak.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:169873 Archived-At: > From: =D3scar Fuentes > Date: Tue, 25 Feb 2014 20:50:11 +0100 >=20 > Eli Zaretskii writes: >=20 > >> Nobody can parse C++ reliably. GCC has given up on trying to te= ach > >> Bison (aka LALR(1) and then some) how to parse C++ and has imple= mented > >> its own hand-written parser. > > > > I understand the potential difficulties, but since we only need a > > relatively small part of parsing, >=20 > Why do we need a small part of parsing? For implementing C++ smart > completion on a reliable way, you need semantic analysis. Can you explain why? I'm probably missing something. > Furthermore, people here are talking too much about completion Well, that's the only thing that clang has that prompted this thread, right? > but there are other features that require whole-program semantic > analysis and hence are out of reach of the approaches mentioned her= e > based on gcc spitting not-quite-comprehensive information. Can you list those features? > > perhaps it's worth trying first? If push comes to shove, what wa= s > > implemented in GCC can be reimplemented in Emacs Lisp, no? >=20 > Right now the available systems for smart code completion are annoy= ingly > slow. They are implemented on C/C++. It is reasonable to expect fro= m a > Elisp-based solution to be unbearably slow, not to mention the > complexity. We can always prototype in Lisp, then reimplement the slow parts in C if needed. > Why reinvent the wheel? Because we cannot get the one that's already invented?