From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Louis_H=c3=b6fler?= Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Thu, 22 Oct 2015 23:47:38 +0200 Message-ID: <5629597A.10701@mathematek.de> 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> <562592ED.1070104@siege-engine.com> <56262577.70107@yandex.ru> <562702C2.6070505@gmail.com> <56276ECE.3090508@yandex.ru> <56281747.9050305@gmail.com> <56282664.3000409@yandex.ru> <56283D79.2070904@gmail.com> <5628C5E7.5060803@yandex.ru> <5628DD6C.6000408@gmail.com> 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 1445550529 25895 80.91.229.3 (22 Oct 2015 21:48:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 21:48:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 22 23:48:34 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 1ZpNis-0004J8-2a for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 23:48:34 +0200 Original-Received: from localhost ([::1]:34744 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpNir-00078D-J6 for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 17:48:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpNi2-0006LP-Hs for emacs-devel@gnu.org; Thu, 22 Oct 2015 17:47:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpNhx-0000Qa-IR for emacs-devel@gnu.org; Thu, 22 Oct 2015 17:47:42 -0400 Original-Received: from mathematek.de ([5.9.124.170]:51693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpNhx-0000PQ-AH for emacs-devel@gnu.org; Thu, 22 Oct 2015 17:47:37 -0400 Original-Received: from [192.168.2.100] (p5B2CE976.dip0.t-ipconnect.de [91.44.233.118]) (Authenticated sender: louis.hoefler@mathematek.de) by mathematek.de (Postfix) with ESMTPSA id 484CD15C232E for ; Thu, 22 Oct 2015 23:47:35 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5628DD6C.6000408@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 5.9.124.170 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:192433 Archived-At: Hello everyone, I followed that topic with much interest. I developed a starting point of a IDE implementation in emacs. http://scm.mathematek.de/index.cgi/emacside/index It is not nearly finished, but I use it for my daily work. Most ide's I started to use have tons of options but don't do the core things well. For me it is important to have a ide which: 1. Does not break 2. Does not change I even do not need colored editor output, I just want a working IDE. An IDE is in my point of view, a toolset which allows me to compile things fast, and do repeating processes without much time loss. I dont like IDE environments where you need 200 Dialogs to reach functions. My package currently can do compilations, and I started to implement a emacsserver API, so that you can send a compilation configuration to a remote Computer, which does the compilation. If you want to have more functions arround that, you can just hack some elisp code arround each executed command with hooks, so you can get full debugger functionalities. Running gdb after a compilation for example, throws me directly into the debugger environment, where I can set breakpoints etc. This is a out-of-the-need 1-man project. So you can't expect it to be as complete and functional as other packages with many contributors. For me personally, the simple things are the ones I continue to use nowadays. The complex things are those who break from time to time. Zero administration is one of the biggest concerns if I start to use software. Greetings, Louis Am 22.10.2015 um 14:58 schrieb Eric Ludlam: > On 10/22/2015 07:17 AM, Dmitry Gutov wrote: >> On 10/22/2015 04:35 AM, Eric Ludlam wrote: >> >>> I'm not sure what is relevant here as far as listing features. There >>> are >>> 12 minor modes that come with semantic doing various diverse things. >>> Things like idle-summary-mode will show you an api summary of the >>> symbol >>> under point. >> >> Robe already supports eldoc-mode. If idle-summary-mode has some UI >> advantages, I believe they should be folded into eldoc-mode as well. >> > > Semantic's idle process handling makes sure databases are synchronized > once, then enables tools to run after, so it is more about the > scheduling of different tools that use semantic. > > In addition, by going through the semantic version, there are a range > of different formatting options to use that the user can select from. > That doesn't require idle-summary-mode, but is a side effect of using > semantic to extract contextual information. > > Also, eldoc only supported Emacs Lisp and no extensions when I wrote > the semantic idle handler. Other features of idle-summary-mode would > port fine between either. > >>> There is COGRE which can pull data from the >>> buffer, reference some databases, and pop up a uml diagram of your code >>> which is a bit over-the-top. >> >> COGRE sounds good, but I imagine it'll need more support than just >> dumping the AST. >> >> And I can't get it to do anything (here's the documentation for >> automatic generation: >> http://www.randomsample.de/cedetdocs/cogre/Semantic-Support.html#Semantic-Support, >> and trying to interact with the editor manually leads to "eieio-oref: >> eieio-oref called on a class: cogre-class", etc). >> >> It's also not in Emacs, for some reason. > > It was deemed optional when Yidong merged CEDET into Emacs. You will > probably need to use Emacs24 to make it work. To try it out do this: > > 1) Install graphviz (it uses that for the layout engine) > 2) Start emacs 24 > 3) Use CEDET from it's git repository > 4) M-x find-library RET cogre RET > 5) find cogre-element-peer in the code > 6) M-x cogre-uml-quick-class RET > > should get you something to play with. > >> (*) Other things that the users ask for is fuzzy completion, showing >> completions right away after dot (Robe isn't fast enough for that) >> and working over TRAMP inside a Vagrant environment. It doesn't seem >> like CEDET integration will help with any of those. >> > > CEDET is a framework that provides an abstraction for connecting > different tools that need to talk about hard problems together. The > problems it solves are related to project information, abstracting > 'tag' information down to something Lisp programs can reason on, and > abstracting code generation into a scheme that can allow lisp programs > to support multiple languages. CEDET doesn't have 'fuzzy completion' > but it can feed a fuzzy completion engine. CEDET doesn't do anything > special with TRAMP, but someone could use CEDET to bind that workflow > into the common workflow. When thinking about CEDET, it isn't about a > bullet list of user facing features but about how it can enable > someone working on said feature to have their work leveraged to a > wider audience. > > Eric >