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: Sat, 01 Mar 2014 10:00:40 +0200 Message-ID: <83ob1quz4n.fsf@gnu.org> References: <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> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <834n3lzux6.fsf@gnu.org> <87ppm9d3y4.fsf@wanadoo.es> <83ob1ty4qr.fsf@gnu.org> <87ha7lcxki.fsf@wanadoo.es> <83ios0xwcv.fsf@gnu.org> <87bnxscr0x.fsf@wanadoo.es> <83eh2oxpnw.fsf@gnu.org> <877g8gcl52.fsf@wanadoo.es> <871tyn4n1l.fsf@fencepost.gnu.org> <531054E2.6040200@dancol.org> <87k3cf3601.fsf@fencepost.gnu.org> <531060AA.8040103@dancol.org> <838usvw9zm.fsf@gnu.org> <531104D9.4050601@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1393660849 30167 80.91.229.3 (1 Mar 2014 08:00:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 08:00:49 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 09:00:58 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 1WJeqv-0000tn-KR for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 09:00:57 +0100 Original-Received: from localhost ([::1]:54623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJeqv-0006hb-9m for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 03:00:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJeqm-0006hD-7W for emacs-devel@gnu.org; Sat, 01 Mar 2014 03:00:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJeqh-0007u5-D6 for emacs-devel@gnu.org; Sat, 01 Mar 2014 03:00:48 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:44318) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJeqb-0007s5-GV; Sat, 01 Mar 2014 03:00:37 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N1Q00800YXCA800@mtaout28.012.net.il>; Sat, 01 Mar 2014 10:00:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1Q003VMZLK1K60@mtaout28.012.net.il>; Sat, 01 Mar 2014 10:00:56 +0200 (IST) In-reply-to: <531104D9.4050601@dancol.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:169974 Archived-At: > Date: Fri, 28 Feb 2014 13:51:21 -0800 > From: Daniel Colascione > CC: dak@gnu.org, emacs-devel@gnu.org > > >> http://pdf.aminer.org/000/542/897/incremental_analysis_of_real_programming_languages.pdf > > > > Not sure what is the point you wanted to make with this (old) > > article. Can you clarify? > > I'm trying to debunk the argument that the features we're talking about > require per-keystroke reparsing of the entire compilation unit. There's > a pretty decent literature in incremental parsing algorithms that might > be efficient enough to make online updating of syntax trees viable. Are there any implementations of these R&D papers in popular compilers (apart of Visual Studio, which is obviously not interesting in this context)? Isn't it true that all the packages that use clang for completion save the buffer whenever completion is required? At least the one I tried did just that, which sounds an awful design decision to me. Since when do we let a feature decide for the user when to save the buffer she is editing?