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:20:35 -0600 Message-ID: <858usy51p8.fsf@stephe-leake.org> References: <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1393363245 25294 80.91.229.3 (25 Feb 2014 21:20:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 21:20:45 +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:20:52 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 1WIPQp-0000XJ-2Y for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 22:20:51 +0100 Original-Received: from localhost ([::1]:37138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPQo-0005j8-MJ for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 16:20:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPQh-0005iz-31 for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:20:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIPQb-0003Mu-O9 for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:20:43 -0500 Original-Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.230]:16717 helo=cdptpa-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIPQb-0003Mq-8w for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:20:37 -0500 Original-Received: from [75.87.81.6] ([75.87.81.6:50531] helo=TAKVER) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id EA/7B-30151-4290D035; Tue, 25 Feb 2014 21:20:37 +0000 In-Reply-To: <8761o3dlak.fsf@wanadoo.es> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Tue, 25 Feb 2014 20:50:11 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.166.230 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:169875 Archived-At: =C3=93scar Fuentes writes: > 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. +1 Refactoring tools, for example; rename this class member function, and all references to it, but _not_ references to the same name in _other_ classes, or the same name declared as a local variable. Do rename in classes that derive from this class. AdaCore GPS does this, for Ada and C++. >> 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. Especially when one of the possible completions is a list of parameters for a function call. --=20 -- Stephe