emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDE


From: Oleh Krehel
Subject: Re: IDE
Date: Mon, 12 Oct 2015 13:05:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> For feature parity with Intellij IDEA and MS VS, we should be able to
> display the list of completions and documentation for the currently
> selected completion in two separate popups:
>
> https://i-msdn.sec.s-msft.com/dynimg/IC797655.jpeg
> https://www.jetbrains.com/img/webhelp/idea/constructors_docs_in_completion.png

I like the first style a lot more. The second looks a lot like the ugly
mess of Eclipse.

Here's what's currently possible in Emacs for C++:

- show function arguments and docstring in an overlay:
    http://oremacs.com/download/fa-do-comments.png
- complete class member at point:
    http://oremacs.com/download/function-args-qt.png
- jump to tag in directory:
    http://oremacs.com/download/function-args-boost.png

The latter two can be done with powerful regexp-based completion, which
MS VS likely still doesn't include.

What's missing, compared to the MS VS picture:

- Candidate completion is in the minibuffer instead of at-point.
- The docstring (only the comment part) is shown separately.

The first part is just Emacs' style of doing things: we usually enter
stuff in the minibuffer, so it makes sense for completion to display
there.  The second part is arguably unnecessary: I usually just jump to
definition of symbol rather than look at the docstring inline.

What's missing, in my opinion, is only faster and more precise parser
(CEDET, GCC etc). For example, currently `semantic-fetch-tags' parses
public/private/protected labels as tags, instead of applying these
properties to actual tags. If that were so, it would be very easy to add
a public/private/protected icon to each tag, just like MS VS does it.

Another example is the QT code: it's a popular LGPL C++ framework that's
currently hard to setup for CEDET.
For instance, `#include <QtGui/QPushButton>` is a plain file without an 
extension with only this code inside:

    #include "qpushbutton.h"

Since the extension isn't recognized, it's not parsed by CEDET.  And I
have to write `#include "qpushbutton.h"` in my application instead of
the more preferred `#include <QtGui/QPushButton>`, because that way I
get tag completion.

These small things are what the competing IDE have been incrementally
improving over the last 20 years. I think we have a serviceable
foundation for C++ completion, it only needs to be polished *a lot*
more.

I also think that the way to do it right would be to integrate with GCC
for code parsing, for reasons of speed and precision.  As I mentioned
before, CEDET is usable, but it can't be as fast and as precise as
GCC. Add to that that the language standard is updated every 5 years or
so with new syntax. GCC has the people to update the parser
accordingly. Doing so for CEDET would be a duplication of effort, and we
don't have the people to do it anyway.

Could someone explain to me if making GCC the dependency of Emacs would
be a good idea, from technical and freedom point of view?  Personally, I
wouldn't care if Emacs executable would get inflated a bit more, if that
meant access to true IDE features, which are only possible with a
precise and fast parser.

    Oleh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]