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: Sun, 18 Oct 2015 13:56:11 +0200 Message-ID: <87bnbwl7ac.fsf@isaac.fritz.box> References: <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> <87k2qlldny.fsf@isaac.fritz.box> <5622AD4D.3010504@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445169406 25198 80.91.229.3 (18 Oct 2015 11:56:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 11:56:46 +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 Sun Oct 18 13:56:36 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 1ZnmZn-00028o-T8 for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 13:56:36 +0200 Original-Received: from localhost ([::1]:33355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnmZn-0005kw-1K for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 07:56:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnmZZ-0005ke-3k for emacs-devel@gnu.org; Sun, 18 Oct 2015 07:56:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnmZV-0006JC-2P for emacs-devel@gnu.org; Sun, 18 Oct 2015 07:56:21 -0400 Original-Received: from randomsample.de ([5.45.97.173]:37978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnmZU-0006J1-Mb; Sun, 18 Oct 2015 07:56:16 -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=St1mjBdLS98y7ub6S9nBbcfghQffsEzImea4YXGB40o=; b=U4uQhkTjuwLGdm2nW89h12MtD+6gDfbLYtr2fAfBfe6OdMC12vgc8JX52uesmekpGJkt15gubfX372wVL/YxBVW7NsSVu7QaWywcv8XJ1ucH0RunbBzfEDveuGJz62af; 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 1ZnmZT-0005eU-Do; Sun, 18 Oct 2015 13:56:15 +0200 In-Reply-To: <5622AD4D.3010504@yandex.ru> (Dmitry Gutov's message of "Sat, 17 Oct 2015 23:19:25 +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:191935 Archived-At: Dmitry Gutov writes: > On 10/17/2015 06:26 PM, David Engster wrote: > >> 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. > > Maybe not the database, but the "tag" value is used in many places in > Semantic. I'd want to be able to use them for, say, JavaScript as > well. For instance, in semantic-symref, not just for completions. In dynamic languages, you would mostly have tags with no specific type. >> 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. > > I'll have to check it out later. It is only upstream, and I wouldn't be surprised if it is broken by now due to changes in mozrepl (this is why I don't like depending on external binaries). I don't code Javascript anymore. >> 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. > > I'm sure it can be implemented in Elisp, just surprised it hasn't been > taken care of since a similar example came came up 6 (or 12?) months > ago, in a Clang-related discussion. Well, it's not like a bunch of people are hacking on the C parser. Several things happened: - Emacs switched to git, so CEDET had to switch as well, which broke my merge setup. I still need to repair it, which is extremely boring work. - CEDET does not work with Emacs25 due to large changes in EIEIO. Someone has to fix that as well. Again: extremely boring work. - This gcc-AST discussion. - New kid. - In general, hacking Emacs isn't as much fun as it used to be. >> 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. > > C-like languages - probably, but every one also has tiny peculiarities > which have to be handled in a different way. Which is why Semantic allows to tweak pretty much any part through mode-local overrides. > But Emacs users are a diverse bunch, and for many the draw is in being > able to use many different languages, including very young ones. So a > general IDE solution should anticipate having to handle different type > systems. Of course. That's the goal of CEDET. If it had just focused on C/C++, it would be simpler. >>> 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. > > I'm glad we agree on this. But Java has also become more complex > (since 1.5, maybe?), and Java 8 added lambdas, which allow omitting > argument types. Yes. If people want to hook in Eclim or whatever, that's fine be me. But it's always the same thing: Those people are *only* iterested in Java, and they don't want to bother with the bigger picture. This is exactly why we have a plethora of solutions for different languages at the moment. > Not sure about things about Objective-C land. It's deserted and people move to Swift land. > But otherwise, if it'll be common to use an external tool for type > resolution, and even parsing the buffer contents, maybe at some point > you'll deprecate Wisent grammars. Or use, say, a very simplified > format for them, only what's strictly necessary to find the names and > boundaries of tags. Maybe. >> 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). > > That's not really true. IntelliJ IDEA supports a big swath of > languages, and my colleagues use it successfully for our > "non-standard" Ruby projects (no Rails), and also with JS and > different markup languages. But of course you have different > challenges with C++, and the JetBrains team has more manpower anyway. Yes, and do you know how the Jetbrains guys achieve this? They have an extensive framework for writing grammars, lexers, etc. Those guys are weird! > But I'd be ecstatic to even have a consistent UI for features that VS > Code (smaller cousin of Visual Studio) touts here: > https://code.visualstudio.com/docs/editor/editingevolved Ever tried to load some random make-based C++ project into Visual C++? -David