Re: IDE

[Eli Zaretskii]

> From: Oleh Krehel <address@hidden>
> Date: Mon, 12 Oct 2015 13:05:02 +0200
> Cc: martin rudalics <address@hidden>, Eli Zaretskii <address@hidden>,
>       address@hidden, address@hidden
> 
> > 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

Talking just about the visual appearance of these, IMO using overlays
limits us in our choice of faces, and fonts.  So I think it's better
to use tooltips or menus or maybe specialized small frames (which are
just tooltips with some limitations lifted and with automatic hide
action removed).

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

This aspect is orthogonal to the visual appearance, I think.

> 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.

IMO, we should support both the "traditional" Emacs style, and the
style users expect because other IDEs provide them.

> 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.

Good C++ support indeed requires to be able to DTRT with
extension-less header files.  It would be good to add such a feature,
e.g. via magic-mode-alist and some creative regexp or match function.

> Could someone explain to me if making GCC the dependency of Emacs would
> be a good idea, from technical and freedom point of view?

You mean, invoke the compiler as part of some command?  No problem at
all (we actually do that already in a couple of commands).