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, 10 Oct 2015 13:14:53 +0300 Message-ID: <5618E51D.4070800@yandex.ru> References: <5610207A.2000300@harpegolden.net> <83fv1r3gzp.fsf@gnu.org> <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> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> 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 1444472118 23018 80.91.229.3 (10 Oct 2015 10:15:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 10:15:18 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 12:15:13 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 1ZkrBF-0004OB-RX for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 12:15:10 +0200 Original-Received: from localhost ([::1]:44301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrBA-0001wW-8J for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 06:15:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrB6-0001wE-Pl for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:15:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkrB3-0002Ef-JO for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:15:00 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:34418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrB3-0002Ea-CC; Sat, 10 Oct 2015 06:14:57 -0400 Original-Received: by wicfx3 with SMTP id fx3so98966662wic.1; Sat, 10 Oct 2015 03:14:56 -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=gGV5PJPq0Y7YfTqbC1k9U41oTUrd9RD2uTxoz54Se1w=; b=Hvi1Si0FC8LozXLZARPot0+9Uelbx6kwg7UmJswaK9KJ/T5b4AmBy9OvgyMagUivIp Y5hbBLtMx672ueJSaHM7O4y/+iYH29BXFKc7KVrDX7VW1a9cH5iomEC5X51W9BZcm3qi WEUVDZnW/YYUXlib+JCNX8q1JwErfH6eHKHdq0keIjotkz7pPfvglkikgwXxWHeMBng+ 0LYGx0nW9xMGuHT32uV+hRmyLg3l561/NYxp3y+nKTt+eU1XOscrES1b+JQF6TYP8gsI +NNdMlfuHIbTo2TgdGAtK0j7RzqPEHzpAv6XSU+Nu6U2whlkaC4d9CfVTek5RfnB2Qac TL6w== X-Received: by 10.195.17.163 with SMTP id gf3mr2865519wjd.105.1444472096710; Sat, 10 Oct 2015 03:14:56 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id uq5sm7213831wjc.3.2015.10.10.03.14.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Oct 2015 03:14:55 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <831td3t62e.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22a 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:191111 Archived-At: On 10/10/2015 12:40 PM, Eli Zaretskii wrote: > I didn't ignore that. I just don't see an effort to make Emacs a > modern IDE. Working on separate parts of that in separate > uncoordinated activities is not the way we should pursue this, IMO. At least we "have volunteers" for that. > It's inefficient at best, and at worst will end up with those > uncoordinated parts falling into oblivion when their driving forces > move on. That would be accurate to say about projects at early stages of development, but the respective third-party packages already work now. If anything, we could keep them working, even Emacs undergoes large internal changes. > It needs to be actively developed. Much more actively than it is now. I suppose. > I don't know. It's for someone who will work on this to find out. I > know that a motivated individual in the GDB development team already > based a useful set of commands on it -- you can compile and inject > code into your program while debugging it. That seems orthogonal to code completion capabilities, for where I'm standing. But I'm not a good person to judge. This does make a good material for a feature request for Irony, unfortunately. Someone more knowledgeable should do that instead. >> We definitely could have more in this department, yes. But what would >> you even call an "IDE mode"? A fixed multi-window setup a la ECB? > > I don't know, and neither do we as a project. A useful step would be > to produce a detailed answer to that question. That answer could both > serve as base for useful discussions, and might provide some anchor > for all those external packages you mentioned to target some coherent > vision. "We need a common interface for refactoring tools" sounds like a good problem statement. I hope that capability can grow from the xref interface, but that needs more work and thought. > I don't believe comprehensive features such as IDE can be developed > exclusively bottom up. There should be some basic set of assumptions > and design rules/decisions that everyone should target and abide by. > There should also be some unified leadership. A comprehensive set of IDE features might be too lofty a goal for us, in the foreseeable future. > We didn't even decide that we want that as our mechanism. Did anyone > consider how this compares with what the other modern IDEs offer? completion-at-point-functions is the API for backends to implement. We have a few frontends for it already. Company can use it, for one. > What if we build our completion on a UI that today's developers will > dislike? Unlike with many traditional Emacs features, which were > developed when there was no prior art, the IDE features have lots of > prior art. No need to invent the wheel, just implement similar look > and feel. Hence we're bundling Company.