help-gnu-emacs
[Top][All Lists]
Advanced

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

Fwd: A guide on setting up C/C++ development environment for Emacs


From: Tu Hoang Do
Subject: Fwd: A guide on setting up C/C++ development environment for Emacs
Date: Thu, 28 Aug 2014 01:14:09 +0700

>
>  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 <address@hidden>
wrote:

>
>
>
> 2014-08-27 18:53 GMT+04:00 Tu Hoang Do <address@hidden>:
>
> 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 <address@hidden>
>> wrote:
>>
>> >
>> >
>> >
>> > 2014-08-27 17:18 GMT+04:00 Tu Hoang Do <address@hidden>:
>> >
>> > 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....<file> 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.
>
>


reply via email to

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