From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Mon, 12 Oct 2015 16:08:29 +0200 Message-ID: <87d1wk18o2.fsf@gmail.com> References: <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <5618E51D.4070800@yandex.ru> <83twpzrp05.fsf@gnu.org> <5618ED93.8000001@yandex.ru> <83lhbbrnn7.fsf@gnu.org> <56191D6B.8040405@yandex.ru> <838u7assvj.fsf@gnu.org> <561A3582.5080806@yandex.ru> <561A3756.1010404@gmx.at> <561A41CA.6060908@yandex.ru> <87io6c5ov5.fsf@gmail.com> <561B999D.2060900@yandex.ru> <871td0460p.fsf@gmail.com> <561BB6B9.5030108@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444658928 16662 80.91.229.3 (12 Oct 2015 14:08:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 14:08:48 +0000 (UTC) Cc: martin rudalics , Eli Zaretskii , adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 16:08:43 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 1ZldmL-0003AS-Eb for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 16:08:41 +0200 Original-Received: from localhost ([::1]:55647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZldmF-00048d-R9 for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 10:08:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zldm0-00047q-LR for emacs-devel@gnu.org; Mon, 12 Oct 2015 10:08:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zldlv-00057d-Kz for emacs-devel@gnu.org; Mon, 12 Oct 2015 10:08:20 -0400 Original-Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:36877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zldlv-00057V-Bj; Mon, 12 Oct 2015 10:08:15 -0400 Original-Received: by wijq8 with SMTP id q8so59775582wij.0; Mon, 12 Oct 2015 07:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=NYqvum1D8wnlypqZ4bEgWD+d9KwQ7bsbsrlrNaupAE8=; b=b3/R7hEdUmHKkcBiJGhJd/F/ZPymb442IRB1kTxTS2Jx9gwrT9MyPXL3ABHUKl1UMt +NrwYoui3d797zXS5TV5TRTT9efTtjUojZ3tK4IBHhFSxTdnsaaNYKRn1/hkp4a8eMT+ uO+vgtNEdEhqU0Az+39qyqQJe9qgsZbITZuJSk04FtQ7xi43Em0wSVrv6fPHeJar6IHT kg4jS1A/Dr6nNubOUE8ESo3vQELU40vGHBJ5d8DgMuCx21oplbZAaTIaM/XnTbP+Co9c GWnMbQe1Ti1UWYzhxu3deSBp4LRWSYKS63Uuei8krcjMAzN6duK+9gtJzJ8pp2b1Hp9a UpdQ== X-Received: by 10.180.87.138 with SMTP id ay10mr15694898wib.12.1444658894087; Mon, 12 Oct 2015 07:08:14 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id m6sm11027552wif.11.2015.10.12.07.08.12 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 12 Oct 2015 07:08:12 -0700 (PDT) In-Reply-To: <561BB6B9.5030108@yandex.ru> (Dmitry Gutov's message of "Mon, 12 Oct 2015 16:33:45 +0300") 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: 2a00:1450:400c:c05::22c 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:191337 Archived-At: Dmitry Gutov writes: > Not sure how looking at Atom would help, but you should absolutely try > it. It's Free Software, after all. Thanks for mentioning that. I wasn't sure that was the case. >> Here's what (semantic-fetch-tags) returns: >> >> ... >> A similar data structure *has* to be somewhere in the GCC innards: it's >> a first step for compilation. In addition, this information is used to >> point out compilation errors/warnings. >> This data structure would know all defined functions/variables/types. >> For instance, it would know that the class QPushButton is defined in >> qpushbutton.h at line 57, and it inherits from QAbstractButton. > > You have to find out what the type of the call target is, first. > > In your example, it's rather easy: "QPushButton quit" is right on the > previous line. > > But what if we're at the end of a chain of calls, like > > app->window->resolve_handler(bar).| > > ? > > And resolve_handler is overloaded, and its return type is dependent on > the type of its argument? CEDET already resolves these complicated chains pretty well, as long as it's got the correct AST. > What if `bar' is declared as `auto' (see C++11)? Or `app' itself? This would be harder, but still very doable, even within CEDET. Now, there are several issues standing in the way of getting the correct AST: 1. Finding where the relevant headers are located on the file system. This means that the AST parser should hook into the currently used build system, and correctly see which #ifdef switches apply where. Only GCC or its likes have access to this info always. To reiterate, if the program compiles with GCC, the exact same switches must be passed to the AST parser, so that it parses exactly the same headers in exactly the same way. 2. Parsing the newly introduced language features. Here CEDET and cc-mode are behind because of the shear complexity of the full C++ syntax. However, GCC does it very well. I've been working on function-args.el to extend CEDET C++ support for my uses for around 2 years now. The most common error that I have to work around is "Type definition not found", which happens either because the header path wasn't resolved, or the wrong #ifdef path was taken. And, of course, there's the issue of Elisp speed. While jumping to a C tag in emacs/src, I collect the tags from 190 files in that directory. They are all pre-parsed by CEDET, totaling to 19460 tags. It takes more than a full second to just merge these 190 lists retrieved for each file into a single list. It makes me think that maybe that list should be built in an external process. On the other hand, having the full info in Elisp data structures would ease the application development significantly. Oleh