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 23:19:25 +0300 Message-ID: <5622AD4D.3010504@yandex.ru> 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> <87k2qlldny.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 1445113189 4281 80.91.229.3 (17 Oct 2015 20:19:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 20:19:49 +0000 (UTC) Cc: John Wiegley , Eli Zaretskii , emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 22:19:41 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 1ZnXx4-0005SX-1u for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 22:19:38 +0200 Original-Received: from localhost ([::1]:59642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXx2-0002mJ-Ve for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 16:19:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXwy-0002mE-Tl for emacs-devel@gnu.org; Sat, 17 Oct 2015 16:19:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnXwv-0008Ds-MU for emacs-devel@gnu.org; Sat, 17 Oct 2015 16:19:32 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:33766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnXwv-0008Do-Dt; Sat, 17 Oct 2015 16:19:29 -0400 Original-Received: by wijp11 with SMTP id p11so50893096wij.0; Sat, 17 Oct 2015 13:19:28 -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=qo5oSkUxPBb7dL7g5KoOe6HdXQ0EbF2jnaVk0DPZf1U=; b=ovb7lwHrZHX3gsJypjSnz9mbWs4KJ+QETPc/CauIaK4nUP98ttYfIXsJhnw/shbhg+ v3Xgx1QxIqMoj0VfsM5d3vG5Ab4k8/ygI8eRt+OZXlAt4e4NVSAM0a69TzsQjxIAyY1i evDs534Tse2k7WAtW3VZ7FbG1n4oiBe2vbw8lSuGgr87sU5UuMjyJUjQN8sY/oXf6WsX 2Hv7vvVuvpljCUIyw8hTmPofTvvjCwv5VwN8UFXQx9wUVZ8sSsrGh7XiOdAU06tmjsrY IxpB7jE1ksjDf7vJ8pdFjXv5zTsWBnAfaYaqV8RiW1B6B1mR6Oe5+6GUu2E/HHYsdW87 a0WA== X-Received: by 10.180.186.74 with SMTP id fi10mr11629797wic.61.1445113168558; Sat, 17 Oct 2015 13:19:28 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id hs5sm8347887wib.6.2015.10.17.13.19.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 13:19:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87k2qlldny.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::22d 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:191877 Archived-At: 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. > 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'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. > 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. 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. >> 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. Not sure about things about Objective-C 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. > 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. Personally, I'm happy discussing and figuring out the current state of affairs, so that our common understanding goes further than "CEDET didn't live up to its promises" or "don't throw out CEDET, we've got nothing better". The EDE subthread also brought up some ideas for project.el. > 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. 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