From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "John Wiegley" Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 10 Oct 2015 11:31:13 -0700 Organization: New Artisans LLC Message-ID: References: <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> <5618E51D.4070800@yandex.ru> <83twpzrp05.fsf@gnu.org> <5618ED93.8000001@yandex.ru> <83lhbbrnn7.fsf@gnu.org> <56191EBE.5050404@yandex.ru> <83612essaw.fsf@gnu.org> <877fmuix68.fsf@isaac.fritz.box> <8337xispn2.fsf@gnu.org> <56195055.6010409@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444501926 25761 80.91.229.3 (10 Oct 2015 18:32:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 18:32:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 20:32:01 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 1Zkyw2-0001le-JW for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 20:31:58 +0200 Original-Received: from localhost ([::1]:45824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkyw1-0001sQ-Th for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 14:31:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkyvT-0001rE-MR for emacs-devel@gnu.org; Sat, 10 Oct 2015 14:31:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkyvQ-0001zT-EH for emacs-devel@gnu.org; Sat, 10 Oct 2015 14:31:23 -0400 Original-Received: from mail-pa0-x22c.google.com ([2607:f8b0:400e:c03::22c]:36717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkyvQ-0001zK-6Q for emacs-devel@gnu.org; Sat, 10 Oct 2015 14:31:20 -0400 Original-Received: by pablk4 with SMTP id lk4so116299102pab.3 for ; Sat, 10 Oct 2015 11:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=IBhppVe41v9aJNKI3GVDui4x/K4XAoKaMe1m5zwKByE=; b=svQn3sW8iGeuBg1SILTdBKxZNq8Ob+JfeXflFWxZCMzbsp+UcjGa3HUUZ+yT8QPXpC JEx6eYWh3808izdaKbYX26OWmCnQGbetuGWXVGEXLAsivNIOHn9rlFal8BOW1mp8gEiq p5oxJw9b+OUctE1p+jCWV2gYFmIMU5kDTLe+L4+ReCNoqdlPbhEIx34s/VjIljnDXMcM P+2ARZF0BFF7wbC987QyTqoHIE6hdXSxn67MBhhK4p4fEweP2VcVoO3z+cRZKmcWuFFe Ydrm7GGH3fvQmrfDAcuxwDdaTPJe1gmoJ1DtbuqaERs3gWPb+YoJOdOV7nJ7XzFr1S+S iBeA== X-Received: by 10.68.191.200 with SMTP id ha8mr23967936pbc.72.1444501878988; Sat, 10 Oct 2015 11:31:18 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id dd4sm9406875pbb.52.2015.10.10.11.31.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 10 Oct 2015 11:31:17 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id 178B9F275F2C; Sat, 10 Oct 2015 11:31:16 -0700 (PDT) In-Reply-To: <56195055.6010409@gmx.at> (martin rudalics's message of "Sat, 10 Oct 2015 19:52:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22c 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:191160 Archived-At: >>>>> martin rudalics writes: > I never use side windows so I can't tell whether they still work. I have > written a frame-tabs.el package based on side windows but I don't use that > either. At the time I installed the side windows functions I also added a > texinfo section but Stefan later asked me to remove it. That info does not > reflect later changes to the code so it might be outdated. You have to live > with the doc-strings which should be fairly accurate. We should define what we want from a "more IDE" Emacs. For example, I do not want window-layout functionality. That's a presentation aspect of IDEs that's entirely separate from what I want from them. Right now we have a pretty nice infrastructure for things like indenting code. That is, there are standard keybindings (TAB, C-M-\), a standard per-buffer override variable (indent-line-function), a standard command (indent-according-to-mode), and ways for packages like Yasnippet to override the meaning of TAB without ruining functionality. I think that what an "IDE is" has little to do with what it looks like. Emacs being a better IDE, to me, means making IDE-like functionality a first-class citizen, as we do with indenting. This would provide a core for fancy display modules to build on top of. I also don't think core Emacs should *provide* this functionality, since that's impossible, given how many different languages and use cases there are. It's more about giving developers a common API to base their work on, so that we maximize collaboration between them. Here is a list of functionality I think should be first-class, structurally speaking (that is, an API will exist, but it may not do anything until a contributor implements the functionality for their language). The ones with a * mean areas where we're already succeeding to some degree: * indentation (see above) reformatting * syntax highlighting (font-lock) help at point documentation lookup (sadly, fewer projects use Info these days) ? completion refactoring semantic editing (for example, paredit) * compilation (M-x compile) live compilation (flymake/flycheck) * REPL (comint) running tests * debugging (GUD) * version control (VC) profiling code coverage app interaction The reason I don't have a * next to completion, despite having so many things capable of doing it (company, auto-complete, ido, hippie-expand, helm, ivy, etc., etc.), is that there are too MANY ways to do it. This is where I think proper IDE support could help. If we have a single paradigm for "determining interesting details about the buffer, and near point", with the ability to refine the query based on what is need, optionally cache results, etc., then the competing libraries we have today could share functionality. The present day `all-completions` function is too spare to fit this bill, so it's less of an IDE feature in my book and more just a Lisp library function. For example, I've written nearly the same backend code for at least 4 different completion/lookup packages, and each time I wonder how we could do better here. The differences are so minimal. To reiterate: I think Emacs becomes more of an IDE when it provides the backbone of an IDE, and not when it looks like one. We have some pieces of that backbone already, which have avoided fragmentation in those areas, but we need more. A standardized way to do tooltips, popups, visual completion selection (or at least the structure), REPLs that interact with buffer contents, etc., would give us a foundation to move to the next step. John