Re: IDE

["Louis Höfler" <louis.hoefler@mathematek.de>]

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
>