From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: raman Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 10 Oct 2015 16:26:17 -0700 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 1444519615 11081 80.91.229.3 (10 Oct 2015 23:26:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 23:26:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 11 01:26:39 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 1Zl3XD-0008Or-Ie for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 01:26:39 +0200 Original-Received: from localhost ([::1]:46672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3XC-0005SF-Pu for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 19:26:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3Wz-0005Rz-Ot for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:26:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zl3Ww-0005ej-Fl for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:26:25 -0400 Original-Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:35929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3Ww-0005eD-8W for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:26:22 -0400 Original-Received: by pablk4 with SMTP id lk4so119793059pab.3 for ; Sat, 10 Oct 2015 16:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=spXINXC0s4TmCkEQ6sOhtRdth5tVNuThR5A6xgSY+cI=; b=VcAIvWyFxXe+lw4URgKjYZCv5Jl14QVdLRZbT/9TzPWH0xzRfc4F5tIqGMDYDHUe5P 4jxEzT/r8JeUfcfLAyjMH9MTgT/DKh8FFfmqCcJFeOW3kp1dRm0Yyh0VXelCgRW/lp46 /3d573J9UKR5jvH4/KYCNnKbJGkG3fgl36a4QAZhd9Omu7S28WTQ1VMSHZfkPYQeirhM VQV3PGfD465Ob2cJ44GiGgvGmso69aOQ1yoyFzQOYY08Ipoh3QZVXWLwgiN8HfcesiFD xzxsylIysRErOtIm1574nhWJSvrg13MGfaeeI9J4PW+lYAP2BQ3axfW/N22ay0Ml/Y/m Qlqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=spXINXC0s4TmCkEQ6sOhtRdth5tVNuThR5A6xgSY+cI=; b=iiK2D0ViCG0K+1R8NRdTek2Q+SF1DxmimTVVEmxg5nVvsT4U2CC9TdBFIAJanCHtHz r5Oekg+BICDOgqsCXcgmzdVyK2OV5e/IJsOo5cEB2H1EyXjkywLakyUB4lhNpq/+Idlh 5ZJCtHxLn57qGNcoRYzEsEynfrbdMZd4bPRxwDNi2oGRwpk4EZS1xpFgjghnQrAi/nB+ MRTXXI46Ex1nE72YNEIFMhu3i1jRtr2Kil7sMDWVXG9UC1wGv4/HDhK9MleAst1mcW05 a2bLGF2E2Kcyuv50Cdo1AcgEMrs8W9ZIyHdKVdu3Cug44p6yhnC9QhOIwor2DuquMp38 njjg== X-Gm-Message-State: ALoCoQn9+7h+FAMs3leydABTFRvlXIK2M7Yb1WaoExZcJMFZKnOBc0nfNE2JUe0aICQmEWYwGMRg X-Received: by 10.68.181.34 with SMTP id dt2mr24787354pbc.7.1444519580733; Sat, 10 Oct 2015 16:26:20 -0700 (PDT) Original-Received: from raman-glaptop2 (c-73-170-121-60.hsd1.ca.comcast.net. [73.170.121.60]) by smtp.gmail.com with ESMTPSA id mk5sm10123881pab.44.2015.10.10.16.26.18 for (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Sat, 10 Oct 2015 16:26:18 -0700 (PDT) In-Reply-To: (John Wiegley's message of "Sat, 10 Oct 2015 11:31:13 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::236 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:191187 Archived-At: "John Wiegley" writes: Well said. Let's focus on functionality -- and the rest -- including a multiplicity of visual look-and-feel setups will follow along with everything else.>>>>>> 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 > --