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: Wed, 07 Jan 2015 20:47:28 +0100 Message-ID: <87wq4ype3z.fsf@fencepost.gnu.org> References: <83bnxuzyl4.fsf@gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420660121 21217 80.91.229.3 (7 Jan 2015 19:48:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2015 19:48:41 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, deng@randomsample.de, "Perry E. Metzger" To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 07 20:48:35 2015 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 1Y8wZy-0000n6-Un for ged-emacs-devel@m.gmane.org; Wed, 07 Jan 2015 20:47:43 +0100 Original-Received: from localhost ([::1]:42532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8wZy-0003an-D1 for ged-emacs-devel@m.gmane.org; Wed, 07 Jan 2015 14:47:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8wZv-0003aV-5t for emacs-devel@gnu.org; Wed, 07 Jan 2015 14:47:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8wZt-0007Nv-3v for emacs-devel@gnu.org; Wed, 07 Jan 2015 14:47:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8wZt-0007Nr-0E for emacs-devel@gnu.org; Wed, 07 Jan 2015 14:47:37 -0500 Original-Received: from localhost ([127.0.0.1]:45342 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8wZl-0002Y9-Tc; Wed, 07 Jan 2015 14:47:30 -0500 Original-Received: by lola (Postfix, from userid 1000) id 9FF00E05DB; Wed, 7 Jan 2015 20:47:28 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Wed, 07 Jan 2015 14:25:01 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:181031 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > In a modern IDE, you can complete anything -- struct members or > > object member variables/functions, type names, etc., etc., and you > > need what are essentially compiler data structures to get that stuff, > > and you need the AST to understand the context in which you're > > requesting the completion. > > I am not convinced this requires the entire AST. > I think it could be done with a lot less. > > It certainly can be done with less. For instance, if the code says > > foo.x + bar.y > > or > > foo.x - bar.y > > it makes no difference for completion what that operator is. In C++, I am afraid you are wrong. It depends on what types operator+ and operator- may be defined for. If you define operator+ on a half-group, you won't generally have operator- available. Operator overloading is a reality in C++. For example, << and >> are seriously overloaded for the standard library. > Clearly there is information from the AST that need not be included in > order to fully support completion. Probably. However, if you don't want to cause major pain when reevaluating your requirements, it is important that you don't need to change/recompile several _differently_ maintained and versioned pieces of software in lockstep to adapt to changed requirements. If you can shake plugins interfacing to Elisp out from GCC without having them tied to a particular version of GCC basically on the fly, you don't need to have the whole AST available in a physical form. But the plugin interface then needs to be general and convenient enough to get any aspect of it on-demand. And with regard to enabling undesirable uses of it, I don't see that this buys us significant savings over a non-Emacs specific AST dump. > I think you propose "entire AST" because it is conceptually satisfying > to you, not because all the data in the AST are necessary. > > What data ARE necessary? It depends on the level of sophistication in the editing modes. If we want the editing modes to be able to evolve without being constrained to the GCC release cycles, we need either rather generically useful data, or generically useful GCC extension interfaces. Keeping all of our babies while throwing out all of the bath water for evolving notions of babies and bathwater is not likely to work well. I don't really see that we have much of a chance not to be hobbling us ourselves more in the process than currently hypothetical leeches. -- David Kastrup