From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Thu, 8 Jan 2015 10:49:46 -0500 Message-ID: <20150108104946.32750f84@jabberwock.cb.piermont.com> References: <83bnxuzyl4.fsf@gnu.org> <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> <87wq4ype3z.fsf@fencepost.gnu.org> <20150108083211.5a85a077@jabberwock.cb.piermont.com> <877fwxpb63.fsf@fencepost.gnu.org> <83r3v55me9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1420732271 19918 80.91.229.3 (8 Jan 2015 15:51:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Jan 2015 15:51:11 +0000 (UTC) Cc: David Kastrup , monnier@iro.umontreal.ca, rms@gnu.org, deng@randomsample.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 08 16:51:05 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 1Y9FLw-0003Kz-9A for ged-emacs-devel@m.gmane.org; Thu, 08 Jan 2015 16:50:28 +0100 Original-Received: from localhost ([::1]:46550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9FLq-0000yq-Nq for ged-emacs-devel@m.gmane.org; Thu, 08 Jan 2015 10:50:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9FLZ-0000v8-Nr for emacs-devel@gnu.org; Thu, 08 Jan 2015 10:50:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9FLT-0007oB-LL for emacs-devel@gnu.org; Thu, 08 Jan 2015 10:50:05 -0500 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:34368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9FLH-0007iy-K5; Thu, 08 Jan 2015 10:49:47 -0500 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 9222314D1; Thu, 8 Jan 2015 10:49:46 -0500 (EST) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 599FA2DE9E5; Thu, 8 Jan 2015 10:49:46 -0500 (EST) In-Reply-To: <83r3v55me9.fsf@gnu.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 166.84.7.14 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:181065 Archived-At: On Thu, 08 Jan 2015 17:21:02 +0200 Eli Zaretskii wrote: > I agree, but I think we should get back on track discussing the > technical issues and aspects of building infrastructure for a good > modern IDE using some help from GCC. > > Suppose we did have a way getting the necessary information from GCC > that is not in the form of an AST: what such an information package > would need to include to allow the functionality users expect from a > modern IDE? Here are several sorts of things I really want to be able to do in a refactoring editor: a) Take all instances of a call of the form a(c, d, e) and turn them into a call of the form b(e, d, NULL, c), regardless of what sort of syntactic mess may be associated with the calls -- whether they're on multiple lines or not, whether one of the parameters is a complicated expression that is impossible for regular expressions to parse, etc. I also want to only do this for the instances of the call "a" which are at a particular scope level -- inner definitions of "a" which mask the outer definition should not be touched. All this can possibly be done without an AST, but it is harder, especially given how maddening parsing parameters with regexes can be. b) To do versions of a), in an environment like C++ where functions are overloaded, so it is necessary to distinguish not only scope but also the types of all of the passed parameters so I can know what overload is in question. The passed parameters might be difficult to type -- they be embedded inside macros, or they might themselves be overloaded functions, and pure syntactic analysis cannot distinguish their types, you need more information. Again, perhaps less than an AST could help here, but it would be a big pain. c) To handle something like completing foo. = complex_call. This requires knowledge of the return type of complex_call, which in a language like C++ is a difficult thing to know based merely on syntax. d) To handle c) but in a situation where "foo" is replaced by a macro which has to be expanded and the types of whose return needs sophisticated evaluation even to know which object or struct is being discussed. Again, this is very hard to do purely syntactically or only with object table access. e) To be able to take every instance where a particular definition (including overload) of foo() is called without checking it for a NULL return value and to offer the user the chance to replace it with the text in which foo() is replaced by a conditional that checks foo for NULL. This is (again) difficult to do in the general case without ASTs because it is insufficient just to have symbol tables, you need to actually know what flavor of foo() this is, and to be able to judge the context in which foo() is called. (This is not a theoretical example, I have really wanted to be able to do this. Yes, it would require a line or two of elisp even with an AST being available and a proper API, but that's the whole point of having Emacs!) I can come up with more and richer examples pretty quickly. Perry -- Perry E. Metzger perry@piermont.com