From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 17 Oct 2015 17:26:09 +0200 Message-ID: <87k2qlldny.fsf@isaac.fritz.box> References: <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> <56224B63.3010803@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445095623 18876 80.91.229.3 (17 Oct 2015 15:27:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:27:03 +0000 (UTC) Cc: John Wiegley , Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 17:26:50 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 1ZnTNh-0002Wx-BV for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 17:26:49 +0200 Original-Received: from localhost ([::1]:58657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTNg-00042h-Hd for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 11:26:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTNA-0003sq-9m for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:26:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnTN6-0001KA-V1 for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:26:16 -0400 Original-Received: from randomsample.de ([5.45.97.173]:36792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTN6-0001Jx-KB; Sat, 17 Oct 2015 11:26:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=tNkUSpRueARSfHqNGwpiqso2TNdKJA/+wMwtjM1pP5g=; b=jjvuichQ6Mka+pv145URvikZj4XUQJH9AeQhrIYjQnVmg9B47rpz7dk74HmhVH9bGKk4Cv2cycqi6AJn2/vvGvonY7YjcxWqUFHOwjexPcQA6If38bGhS8PkVKGPtB79; Original-Received: from ip4d1645ea.dynamic.kabel-deutschland.de ([77.22.69.234] helo=isaac.fritz.box) by randomsample.de with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZnTN4-0006w1-Ql; Sat, 17 Oct 2015 17:26:10 +0200 In-Reply-To: <56224B63.3010803@yandex.ru> (Dmitry Gutov's message of "Sat, 17 Oct 2015 16:21:39 +0300") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:191836 Archived-At: Dmitry Gutov writes: > 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. Well, all I can say is it works well. >> 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. The database wouldn't be much of a problem, I think. It's just incredibly hard, if not impossible, to parse such a dynamic language statically. For Javascript, I wrote a small semanticdb backend to query a running Firefox process through mozrepl. That worked pretty well for getting completions on stuff like jQuery. >> 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. I fully agree. The above mentioned mozrepl-binding worked together with our small Javascript parser. >> 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 It's a matter of someone implementing overloads. And such a implementation could be used from any other languages that has overloading on function arguments, which is pretty common. > 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. There are a lot of similarities in C-like languages. Also, any OOP-language will have something like classes, parents, methods, attributes. But yes, type inference and dynamic languages make things more complicated. Querying an external REPL or some tool that analyzes the code would often be necessary. > Type analysis is often at least as complex as parsing (if not > more). For C++11, it has become more complex, which is why I will indeed ask an external tool for type information. Since such a tool will have to build the AST anyway, it will provide that as well. > 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. Yes, of course. To be honest, I mostly lost track about what is actually discussed here. I just took offense at John's "if CEDET was the answer we wouldn't still be asking questions" and avoiding a "CEDET2", like the CEDET we have in core is a failure. CEDET tries to walk a narrow path, trying to provide IDE-like features without Emacs actually becoming a "typical IDE". The IDEs out there have it easier, as they usually force you into organizing your projects in a certain way, and they usually target only one language (or language family). -David