From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 17 Oct 2015 16:21:39 +0300 Message-ID: <56224B63.3010803@yandex.ru> References: <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <871tcyexa9.fsf@fimbulvetr.bsc.es> <87612a7my2.fsf@fencepost.gnu.org> <561DC925.5050001@siege-engine.com> <561E32D2.4060501@yandex.ru> <83wpum3ozk.fsf@gnu.org> <87si59ln6u.fsf@isaac.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1445088117 8609 80.91.229.3 (17 Oct 2015 13:21:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 13:21:57 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: David Engster , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 15:21:51 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 1ZnRQl-00046J-3w for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 15:21:51 +0200 Original-Received: from localhost ([::1]:58307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnRQk-0001dj-9v for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 09:21:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnRQg-0001db-8G for emacs-devel@gnu.org; Sat, 17 Oct 2015 09:21:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnRQd-00076V-3n for emacs-devel@gnu.org; Sat, 17 Oct 2015 09:21:46 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:38789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnRQc-00076R-RB; Sat, 17 Oct 2015 09:21:43 -0400 Original-Received: by wicll6 with SMTP id ll6so44701922wic.1; Sat, 17 Oct 2015 06:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=tFnlJNFf0O7hNHJFQR3l0OvBgFK2LAhGMFo1zWVlSbw=; b=hKLi6ib193tleto6OIhizxisynzqoY+fRatWhLKOZgPk1LPIArlyzFzOHdh5BtFRgt GXBJNtZZLpMr0aoeiYX7CpNCNxc8NiHZjGe9Kd1LUngTm4U9DxU+MimxjAASbd46BkWB FP675Ngnk95UG0cybUKEH2c2/jgJj0aMiMPAW9m5ZicjB8YiOHGrbz5P4QqPBeEs9hhp 7aexb9xXegLiWIL8FAFpkR6JVm6bKUJdte1dItWb8tMxRQiQlPUmEqwwg5OO8vidLvfz W3bbKBt+VpvBDpX9N1wHSf4fICLztm07NQjv3dNBlxh7LweobfTwhlkjsu3sgmrIFV7w H7zQ== X-Received: by 10.194.117.39 with SMTP id kb7mr22410944wjb.129.1445088101871; Sat, 17 Oct 2015 06:21:41 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id jd7sm28365078wjb.19.2015.10.17.06.21.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 06:21:41 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87si59ln6u.fsf@isaac.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::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:191823 Archived-At: On 10/17/2015 03:00 PM, David Engster wrote: > Eli Zaretskii writes: >> I'm quite sure CEDET has collected and expressed in code a lot of >> experience and solutions to many problems that arise in the context of >> building an IDE. It's OK to discard that, if we sure that's the >> proverbial 1st variant everyone throws away, but we need first to be >> sure we know what we are discarding. I wouldn't want to discard Semantic, as long as it works better than the new solution, in the domain that it's actually targeting. And we should learn from its implementation either way. > From the discussion so far, I think the main issue at least w.r.t. to > Semantic is: do you actually want Semantic's tag-based system, or more > general: do you want quick access to AST information in your buffer? Not really the main issue. Whether the AST is saved in overlays (and thus not refreshed as long as buffer is not modified), for me is an open question. But not many of the existing code assistance tools that are currently available, provide that info, at least for dynamic languages. So it would be more productive to focus on the things they do provide, and grow the internal IDE APIs from that. Whenever we have a tool that does provide AST dumps at will, or Semantic supports the language in question well, it would of course be great to use it. > If I understand Dmitry correctly, he is not really interested in that, > as for dynamic languages, the AST information is usually missing > important information (unless you bother to implement a complete > frontend). Not sure what you mean exactly by "complete frontend", but it'll often be missing anyway. If the current method takes 'foo' as an argument, and the method is public, and the method contains 'foo.bar()', often the best thing we can tell about 'foo' is that its class contains a method called 'bar'. So at least the Semantic database would have to be extended to work meaningfully with tags like that. > He'd rather call external binaries for complicated stuff like > completion, and use simpler tools (like pure regexp-based parsing) for > stuff like font-locking, navigation, folding, etc. I mentioned SMIE as well. It's a bit more advanced than that. > Of course, you can > hook external binaries into Semantic pretty easily, but I can understand > Dmitry that if he does not need the rest of Semantic, why should he > bother? Being able to mix and match would be best, of course. > Now, I think having AST information in your buffer is great, and I don't > like depending on external binaries if I don't have to, because I want > as much as possible in Emacs Lisp. For me, that's what Emacs is about > and why I still use it in the first place. My biggest issue with Semantic is that it tries to implement type analysis in Elisp, and still hasn't gotten it right even for simple C++ code (no classes or templates). Allow me to repeat myself with this: https://gist.github.com/dgutov/19c45ef43d1c90b96483 Suggested completions should depend on the argument tee receives ("a" and "b" for i, "c" and "d" for l), but they don't. And I think re-implementing type analysis for each language in Elisp is untenable. Correct me if I'm wrong, but you cannot generalize that logic: different languages have different type systems, and for each one you'd have to write the analysis from scratch. Type analysis is often at least as complex as parsing (if not more). I'm not in any hurry to rewrite e.g. Tern in Elisp, and then keep it up-to-date. And speaking of more personal reasons, I already have written a code assistance tool for Ruby, in Ruby (which is not a Lisp, but still a pretty okay language), and smooth integration with whatever APIs we choose would be nice.