From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tu Hoang Do Newsgroups: gmane.emacs.help Subject: Fwd: A guide on setting up C/C++ development environment for Emacs Date: Thu, 28 Aug 2014 01:14:09 +0700 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 1409163284 20275 80.91.229.3 (27 Aug 2014 18:14:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 18:14:44 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Aug 27 20:14:39 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 1XMhju-0007BX-3Y for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Aug 2014 20:14:34 +0200 Original-Received: from localhost ([::1]:32805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhjt-0003iq-La for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Aug 2014 14:14:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhjZ-0003bb-S1 for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:14:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMhjW-0005z0-Q6 for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:14:13 -0400 Original-Received: from mail-oa0-x22c.google.com ([2607:f8b0:4003:c02::22c]:49398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMhjW-0005yf-Ho for help-gnu-emacs@gnu.org; Wed, 27 Aug 2014 14:14:10 -0400 Original-Received: by mail-oa0-f44.google.com with SMTP id eb12so491242oac.17 for ; Wed, 27 Aug 2014 11:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+nLK+Czw0SGM8RsXOn5B3h1p+H1lQWS7qx2OOnDzo/A=; b=J6Ih0nlOe2beTOkiC6IyRQBhtUBxG/u7C1Ka5BbVJ6+5LGdy/OJwbHsMY0iSVxIU1S g2V2hwJ/RaMSRpB9gkc+x9Q8dI0zZvRfL4Y9ts0yeyIdfb/FNgDGW9k+XBDJqokix/nE N3QUBrtFNwVwOercN80v9hWvDa1nHUh8AQyNp8rOdH+NYzi02+uxKaAE529FGJ1g3JDe +SWyRXFw14WplZBxuSeoCCEdv719caVdyUxNtkL73RC5WBhRhEB9TFQrFIBNYdeyAFQU zv0CTr68SsaX1R5iznm7S7KxMyMqpXp2PTGDz33t3XkYJnBGX2C6Tp1fKuB98SwJabLS c6tg== X-Received: by 10.182.129.230 with SMTP id nz6mr20378874obb.16.1409163249970; Wed, 27 Aug 2014 11:14:09 -0700 (PDT) Original-Received: by 10.76.176.71 with HTTP; Wed, 27 Aug 2014 11:14:09 -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:4003:c02::22c 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:99427 Archived-At: > > 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. > >