From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jai Dayal Newsgroups: gmane.emacs.help Subject: Re: A guide on setting up C/C++ development environment for Emacs Date: Wed, 27 Aug 2014 14:15:17 -0400 Message-ID: References: <513ad0e2-f7f4-484c-b17b-7c94a8c2fc7a@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1409163369 21319 80.91.229.3 (27 Aug 2014 18:16:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 18:16:09 +0000 (UTC) Cc: help-gnu-emacs To: Tu Hoang Do Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Aug 27 20:16:02 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1XMhlI-0008KJ-Kl for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Aug 2014 20:16:00 +0200 Original-Received: from localhost ([::1]:32813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhlI-0004aS-6U for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Aug 2014 14:16:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhl1-0004Zt-EY for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:15:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMhkx-00073V-V4 for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:15:43 -0400 Original-Received: from mail-vc0-x229.google.com ([2607:f8b0:400c:c03::229]:47502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhkx-00073E-6V for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:15:39 -0400 Original-Received: by mail-vc0-f169.google.com with SMTP id le20so29402vcb.14 for ; Wed, 27 Aug 2014 11:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xQZOKt8LxmkykIClG095lKQkZDF3wahrrXqjPSpLFaY=; b=HOJJnns9Tn0L8w6LUt3iSKckEpR4pgYWl3/LFACqkyTYQkPfAJLySGJrfhwfJCKEGz zz+14WYGXvBVvRmoievuWKJs3FnuOuIWrXMaEBXVYXTGpMJGJkNtgDHiJWjvD2oO9Ap3 OXiva4xZdty1njiB05pqUSIX6yks/RzepvonPuz6cyckah0TamL/wPTMeE/IP18vUH+7 W4w2nQLxzWegAuDKaGoSLSpNp97eWW9uNZzbzuILevI/HnYUNROqCiGDYin7utKmquiP uSxMyLI3GOvlMrU3FQOBJdAqQJvNZ9VSoL19GJB/QWcc/re7vWOd8nutX6kk2YTdWzvg GaTw== X-Received: by 10.220.163.130 with SMTP id a2mr2626592vcy.52.1409163338266; Wed, 27 Aug 2014 11:15:38 -0700 (PDT) Original-Received: by 10.221.24.82 with HTTP; Wed, 27 Aug 2014 11:15:17 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c03::229 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:99428 Archived-At: Any mention of CEDET always turns into this kind of discussion. On Wed, Aug 27, 2014 at 2:14 PM, Tu Hoang Do wrote: > > > > Yes, and it seems to me like a reason to not use C++. Really. > > It's has so horrible syntax/grammar (compared e.g. to Lisp), > > so in 2014 there is no complete solution to work with comfort. > > Seriosly, there is a SLIME, there is a CEDET (which works well only > > with C), but there is no complete support for C++ around. Only a > > set of workarounds and disappointments. > > > > Sure, so do I. I took a C job and my C++ is fading away. Probably I only > use C++ as C with classes and templates. For C++, at least Clang can work > with it and I've just added a section on how to use company-clang and > .dir-locals.el to provide project completion: > http://tuhdo.github.io/c-ide.html#sec-2 > > > Yes, I understood about CEDET parsing infrastructure. But the case above > > is about a CEDET bug, rather than caching > > > > Probably. I haven't encountered the problem. For your first CEDET problem, > you can use company-semantic and it will give you completion, even without > anay prefix. > > Or I can just use Qt Creator or just abandon the C++ and do my high-level > > > abstractions and programming in Lisp, and low-level programming in C. > > > > That works fine. I prefer the later. > > On Reddit I had a discussion with another user about IDE like QtCreator vs > Emacs: > > http://www.reddit.com/r/cpp/comments/2efh2c/cc_development_environment_for_emacs/cjz03qr > > I can understand the value QtCreator provides, but when I need to work with > a project with multiple languages (i.e. not only your language source > files, you also have bash scripts, Makefile, test written in other > languages, submodules in other languages...) then Emacs will be better in > general operations. In general, QtCreator provides better C++ support than > most IDEs and editors, include Eclipse. > > > > On Wed, Aug 27, 2014 at 11:21 PM, Dmitriy Igrishin > wrote: > > > > > > > > > 2014-08-27 18:53 GMT+04:00 Tu Hoang Do : > > > > For C, CEDET works really well. For C++, it is a quite incomplete but > >> usable. I already showed the smart completion in this screenshot: > >> http://tuhdo.github.io/static/auto_complete.gif > >> > > > >> > >> Notice in the screenshot before and after I include linux/printk.h > CEDET > >> realizes the change in buffer and adapt immediately. But, as I said, you > >> need to leave it sometimes for parsing the first time you perform smart > >> completion from included files. Here is another example with using CEDET > >> with Boost: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif > >> > >> CEDET actually understands your source code by trying to parse properly. > >> It > >> works mostly with C. > >> > > Yes, and it seems to me like a reason to not use C++. Really. > > It's has so horrible syntax/grammar (compared e.g. to Lisp), > > so in 2014 there is no complete solution to work with comfort. > > Seriosly, there is a SLIME, there is a CEDET (which works well only > > with C), but there is no complete support for C++ around. Only a > > set of workarounds and disappointments. > > > >> > > > >> > >> please, try to M-x semantic-ia-complete- > >> > symbol-menu > >> > when you are in method implementation like this: > >> > void Class::method() > >> > { > >> > // M-x semantic-ia-complete-symbol-menu should show a menu > >> > // with all members in the scope. But nothing is shown. > >> > > >> } > >> > > >> > >> For this use case, I agree this is a limitation. You need to have a > prefix > >> for it to start completion. I think this should be less of a problem > since > >> if you have many include files, you have a huge pool of completion > >> candidates that you have to narrow down anyway. > >> > >> > >> Second example. Please, try to M-x semantic-ia-complete-symbol-menu > >> > when you are in > >> > void Class::method() > >> > { > >> > method2( > >> > // M-x semantic-ia-complete-symbol-menu after the "(" will > >> > // freeze Emacs to do some of stupid thinking. > >> > // Terrible, horrible and sad. And nothing more. > >> > } > >> > > >> > >> Parsing is an intensive task. To make CEDET work well, *you have to > wait* > >> > >> for it to biuld up the database for future use. For an implementation in > >> Pure Elisp, it is quite fast for reasonable size projects and is cross > >> platform. Getting Clang to work on Windows is not easy. Also, it is the > >> limitation of single threaded Emacs. To provides real IDE features like > in > >> other IDEs, Emacs needs must be able to do many things at once, like > >> analyzing and checking. Since Emacs is single threaded, anything heavy > >> weight blocks it. You have to wait for a few minutes if you only include > >> like ten header files and your project is not too large. The way it > works > >> is like this: for each included file, it parse the that file and if the > >> included file includes further files it will move deeply into those > files > >> and parse until reaching the end.* Subsequent parsing results in less > >> time *because > >> > >> CEDET can make use of previous parsing result. I heard that in the > future > >> Emacs will come with cooperative threads, and it makes tasks like > parsing > >> and syntax checking can coexist with editing. > >> > > Yes, I understood about CEDET parsing infrastructure. But the case above > > is about a CEDET bug, rather than caching. You may call > > M-x semantic-ia-complete-symbol-menu after the "(" in the case above many > > times and Emacs will be freezed many times accordingly. > > > >> > >> After this, I don't want to use CEDET without any sorry. > >> > Sorry. > >> > > >> > >> Sure. You always have alternatives such as other Clang solutions. But it > >> won't be complete either. It can complete candidates in system header > >> files > >> fine, but if you want to complete for project wise, you have to give it > >> include paths written in absolute path. > >> > >> Or, you can just use GNU Global with Emacs frontend that provides a not > so > >> accurate for C++ but practical solution. It's really fast. I can walk > the > >> Linux kernel with ease. You can use company-gtags to get a list of all > >> possible completions in your project. > >> > > Or I can just use Qt Creator or just abandon the C++ and do my high-level > > abstractions and programming in Lisp, and low-level programming in C. > > > >> > >> Thanks. > >> > >> On Wed, Aug 27, 2014 at 9:15 PM, Dmitriy Igrishin > >> wrote: > >> > >> > > >> > > >> > > >> > 2014-08-27 17:18 GMT+04:00 Tu Hoang Do : > >> > > >> > CEDET is not slow. It's reasonably fast given it is implemented in > Emacs > >> >> Lisp. It needs time for parsing to build a database, so you see a > >> message > >> >> printing this: parsing.... in the minibuffer. It needs parsing > to > >> >> build up a database for smart completion. After the first time > parsing, > >> >> completion happens instantly and you should enable Semanticdb minor > >> mode to > >> >> save the parsing results, so CEDET won't have to parse the next time. > >> CEDET > >> >> can handle project with the size of Emacs really well. I think even > >> project > >> >> with more than a million lines of code. CEDET is the only viable > >> solution > >> >> so far I found for real smart completion in Emacs. Other clang based > >> >> solution is pretty limited: you can only get completion from system > >> header > >> >> and current directory, but not for your project. You have to add the > >> >> include paths to tell Clang where your project include paths are, and > >> you > >> >> have to specify with absolute paths. It's really tedious. > >> >> > >> > No, it does not real smart. For example, please, try to > >> > M-x semantic-ia-complete-symbol-menu > >> > when you are in method implementation like this: > >> > void Class::method() > >> > { > >> > // M-x semantic-ia-complete-symbol-menu should show a menu > >> > // with all members in the scope. But nothing is shown. > >> > } > >> > Second example. Please, try to M-x semantic-ia-complete-symbol-menu > >> > when you are in > >> > void Class::method() > >> > { > >> > method2( > >> > // M-x semantic-ia-complete-symbol-menu after the "(" will > >> > // freeze Emacs to do some of stupid thinking. > >> > // Terrible, horrible and sad. And nothing more. > >> > } > >> > > >> > After this, I don't want to use CEDET without any sorry. > >> > Sorry. > >> > > >> > -- > >> > // Dmitriy. > >> > > >> > > >> > > > > > > > > -- > > // Dmitriy. > > > > >