From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Mon, 12 Oct 2015 13:05:02 +0200 Message-ID: <87io6c5ov5.fsf@gmail.com> 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> <56191D6B.8040405@yandex.ru> <838u7assvj.fsf@gnu.org> <561A3582.5080806@yandex.ru> <561A3756.1010404@gmx.at> <561A41CA.6060908@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444647933 23784 80.91.229.3 (12 Oct 2015 11:05:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 11:05:33 +0000 (UTC) Cc: martin rudalics , Eli Zaretskii , adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 13:05:17 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 1Zlaum-0004rl-Hl for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 13:05:12 +0200 Original-Received: from localhost ([::1]:54458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlaum-0005sp-0G for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 07:05:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlauQ-0005sS-Ay for emacs-devel@gnu.org; Mon, 12 Oct 2015 07:04:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlauN-0000Ec-4j for emacs-devel@gnu.org; Mon, 12 Oct 2015 07:04:50 -0400 Original-Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:36299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlauM-0000EV-VI; Mon, 12 Oct 2015 07:04:47 -0400 Original-Received: by wicgb1 with SMTP id gb1so144303344wic.1; Mon, 12 Oct 2015 04:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; bh=a8/T5YtOa0MpGHsjkaOUzX9pYV1NydLMEdnQmGQUK2k=; b=YnuUBEx4xV19n2B8yNtAlHHO1NMEuEB8tTQtJN5S304/Tgy6HadrelhJS8ZjvqS4ag m9Tc441kqJ72rW4KzRzKDjA8ChSRl/c89LCgdLMrqh3bOipXM5CGfEdwazyZzFRZUX2f xKDBscB8ermHL21NlGvX/u1Ya5xLmhnbwthaL/f82wqX1GbiPShhZUHEcQjnyy5gudH5 EAEY4XWQP7rvNV4A0CPqWCusRg96QK68/+UjI00RaCS2UxXTP1cLXNAr5KlQYnQGGLbh AJZYisTRDptOIX+LHI1k6AuWC0oMLlMStIkk8Rn9eaw1rNQ3wX72L1BFwb7acVQxHcC+ nPew== X-Received: by 10.195.17.163 with SMTP id gf3mr12828727wjd.105.1444647886074; Mon, 12 Oct 2015 04:04:46 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id i10sm19137636wjz.41.2015.10.12.04.04.45 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 12 Oct 2015 04:04:45 -0700 (PDT) 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: 2a00:1450:400c:c05::232 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:191313 Archived-At: Dmitry Gutov 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 ` 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 `, 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