Clang Complete new try?

[koonschi]

Hello,

I was thinking about the clang complete plugin, and I decided it was time to show that plugin some love. I guess I don't have to tell you how powerful libclang is and what great benefits codeblocks could have using clang for code completion, refactoring etc.

I know that there is already a Clang plugin and I was thinking of extending it at first, but then I looked at the code and it wasn't really easy to read and understand as there were next to no comments and the whole structure of the plugin wasn't very clear to me either.

Now, as it seems to be working (a little at least as I have seen from the original topic of the plugin (http://forums.codeblocks.org/index.php/topic,15521.0.html), I thought of reusing code of this PlugIn to create a new one or refactoring it and then extending it.
I'd like to create a cleaner, well commented version of this plugin that might be delivered with later releases of codeblocks.

On the long term, working on this would not only include code completion, but also a lot of refactoring options. I see huge potential in this.

Now, before I start, there are a few things I want to have clarified first:
Would this be appreciated?
Are there currently similar plans for code completion (i.e. would I do redundant work)?
I guess it could make codeblocks slower, but add a lot of features. What's the opinion on this of the rest of the community?
Would maybe anybody else be interested in taking a serious approach to this, too?

I will not be able to start working on this at once, as I have a lot of other things going on, too. But if the response to this proposal is good, I'd take some time to really dig into libclang and extend this plugin.

Let me know what you think.

Koonschi

[ollydbg]

Would this be appreciated?

Yes, surely using clang code completion will give correct code suggestion list, as you may know, currently, our parser in CC does not handle code(c++ template code)very well.

Are there currently similar plans for code completion (i.e. would I do redundant work)?

The work in ClangComplete plugin is one year ago, currently I see no body was working on this plugin.

I guess it could make codeblocks slower, but add a lot of features. What's the opinion on this of the rest of the community?

Look at CodeLite IDE, it already have clang code completion.

Would maybe anybody else be interested in taking a serious approach to this, too?

I personally do not have much time on playing with clang, but I can be a tester if you go ahead. Thanks.

[oBFusCATed]

Let me know what you think.

The first thing that should be done is improving the C::B's SDK in regard to CC.
Currently it is made with the CC plugin in mind and it is not generic. Writing the plugin probably is not that hard.
But changing the API is and this is what stops me from doing any work in this regard.

[Alpha]

I will probably have time to help this summer.

Another thing to keep in mind, is that other tools can benefit from Clang's knowledge, for example semantic highlight.  An idea is to create a single parser module (Clang), and allow multiple plugins to communicate with it.

[oBFusCATed]

for example semantic highlight.

As you know semantic highlight improvement is limited more by the editor than the parser.

An idea is to create a single parser module (Clang), and allow multiple plugins to communicate with it.

This is why I'm saying we need changes to the SDK.

[golgepapaz]

Guys. I am working on it. Still  much to go though.

Symbol browser



Code completion. Shows the higher priority matches first.



Errors and stuffies


Memory usage. Seems to be the limiting factor (This is a memory usage for single translation unit)

[oBFusCATed]

Great now we will have 3 symbol browsers  

p.s. I doubt you'll be allowed to use M$ icons.

[golgepapaz]

Meh I've pilfered the icons from http://sourceforge.net/projects/symbol-browser/?source=dlp except the private and protected overlays which in turn
might have been copied from visual studio (They look alike but slightly different)
I won't deny VisualAssist is my inspiration though.

[ollydbg]

Guys. I am working on it. Still  much to go though.
...

Great Job!!!
Can you show us the source link so that someone can build and test it? Thanks.

[golgepapaz]

Great Job!!!
Can you show us the source link so that someone can build and test it? Thanks.

Thanks . Unfortunately this is at its preliminary stages and not worthy of publishing yet.(lots of bugs ,frequent crashes)
Since I detest the c interface of libclang I am writing this against the officially unstable c++ libraries
and this stuff is huge and requires more work on my part.But I am getting there...

[ollydbg]

Great Job!!!
Can you show us the source link so that someone can build and test it? Thanks.

Thanks . Unfortunately this is at its preliminary stages and not worthy of publishing yet.(lots of bugs ,frequent crashes)
Since I detest the c interface of libclang I am writing this against the officially unstable c++ libraries
and this stuff is huge and requires more work on my part.But I am getting there...

Ok, I see, When it's ready, I'd like to test it, thanks for the contribution!

[oBFusCATed]

Since I detest the c interface of libclang I am writing this against the officially unstable c++ libraries
and this stuff is huge and requires more work on my part.

Why are you detesting it? Does it limit you? How?
If there is no other benefit other than you feeling happy of using c++ instead of c, then you're doing it wrong.

Because:
1. Use c interfaces are better because they are more stable - most of the time you can update the library without the need to recompile
2. You're not tempted to use modern c++11 stuff (your plugin should compile with gcc4.1 in order to be included in C::B!)
3. You're not tempted to use modern c++ template stuff (makes code slow to compile, produces tons of useless symbols)
4. Most of the times c interfaces are simpler to use and understand
5. If you're serious about your plugin then you'll use the stable interface, otherwise it is just an experiment and then we'll have the same topic started again in an year.

p.s. if you're not using local repo for your project you're also doing it wrong

[koonschi]

Wow this looks amazing.
BTW That's exactly why I was asking if there was already someone working on it

The icons look very MS-ish though, they remember me of my VB 6.0 times.

If you need help, I'd be very happy to assist you.

[Alpha]

I rather prefer Code::Blocks style icons, but that may just be me.

[golgepapaz]

Why are you detesting it? Does it limit you? How?
If there is no other benefit other than you feeling happy of using c++ instead of c, then you're doing it wrong.

Because:
1. Use c interfaces are better because they are more stable - most of the time you can update the library without the need to recompile
2. You're not tempted to use modern c++11 stuff (your plugin should compile with gcc4.1 in order to be included in C::B!)
3. You're not tempted to use modern c++ template stuff (makes code slow to compile, produces tons of useless symbols)
4. Most of the times c interfaces are simpler to use and understand
5. If you're serious about your plugin then you'll use the stable interface, otherwise it is just an experiment and then we'll have the same topic started again in an year.

p.s. if you're not using local repo for your project you're also doing it wrong

1. Well it's just that c interface does not click with me with the necessary indirections and I've wanted
something more powerful than what libclang provides. Although I admit there are not much I cannot do with libclang
until now.
2. Yes I do use c++11 and new standard library features (although nothing major and can't do without boost).I am also
contemplating ditching wxWidgets 2.8.12 in favor of 2.9.5 (hopefully would be released soon) to be able to use CallAfter() (Tree Control double click issue,disconnecting a event
handler inside a handler etc.) and some other stuff. I did not know there was an requirement as such but again I don't expect it to work at every platform for now.
3. I assure you no kittens were harmed when I practice my insane template metaprogramming skills  . Seriously no fancy stuff other than provided by the boost itself.
   Those issues are not a great concern compared the other stuffies and thingies such as speed and memory footprint.
4. That's debatable and up the personal taste but I digress. The point one is the motivation here.
5. It's not that unstable. I would eventually need to delve in the class hierarchy for some stuff I am imagining doing.

p.s. I do have a Git repo set up but I am not using it extensively yet though.

[golgepapaz]

I rather prefer Code::Blocks style icons, but that may just be me.

  Well I am red-green colour blind and do better with shapes than colours.I am yet to see a better icon scheme (personally) than the MS icon library.
I am not comfortable with the C::B icons. It's a nx16 png strip anyway and can easily be replaced with something more suitable if the need arises.
  

[oBFusCATed]

1. clicking doesn't matter if you're serious about it. Because if the interface is unstable you'll loose the clicking and stop working on the project the first time you have to support two-three version of clang or even more. We want to support all distros.
2. see the gcc-4.1 note here. C::B doesn't work well with wx2.9 also I doubt it will be released in the next year or even two
3. boost is the main cause for harmed kittens, don't use boost please if you're serious about your plugin. Every linux distro has its own version of boost, good luck with the compatibility.

You can ignore all of the above if you're just playing and you're not serious (to be involved with the plugin for a long period of time (2+ years))

[MortenMacFly]

You should not wonder that after a while from our point of view its hard t believe in the success of a complete new trial. Looking into the past all such attempts failed.

I can only recommend to use what Eran has to offer: His CC library (if still decoupled from the IDE) is feature-rich, includes clang and ctags and is ready to use. Although I don't want to distract you from what you are doing, but new attempts should seriously believe making use of whats already out there and not something new.

[killerbot]

3. boost is the main cause for harmed kittens, don't use boost please if you're serious about your plugin. Every linux distro has its own version of boost, good luck with the compatibility.

Please stop telling and trashing things. Boost works perfectly nice, it all depends on what you use.

Instead of critiquing we should encourage every attempt, since every attempt might learn us something.
First we need proof of concepts and later in we can see how we can use them.

Have indeed a look at Eran's current state, I did some tests with it a couple of weeks ago, and it had a lot of failures. My code did however contained C++11 code.
But that is also what it needs to support, this is a hard requirement ! We are targeting the future.
Maybe it is good to study Erans work, and see how it can be improved , extended. Personally I would ignore the ctags part, and focus on the clang.


Do take into account, the current things of CB, eg wx2.8.x and not wx2.9. Prefer to use only official things (wx2.9 is beta, for like a zillion years :-(  )

[oBFusCATed]

Please stop telling and trashing things. Boost works perfectly nice, it all depends on what you use.

No it doesn't. Because they break their API. I'm talking from experience here.
I've tried to do an OSS app, which used boost::thread (and some others bind/function, nothing fancy) and had the chance
to try handle interface breakage. It was pretty funny. I've abandoned the project.
Another cool feature of my app was that the debug version was 20mbytes large for 10kloc, the linking wasn't fast.

Yes boost::shared_ptr should work everywhere, but we have cb::shared_ptr, so there is no need to use boost for that.

Boost might be safe to use in a project you're shipping statically linked, where you know the boost version and have tested it.
But not for OSS projects, where the project should work on a random distro with random boost version and compiler.

p.s. the only pluign which uses boost is disabled on centos5, because of too old version of boost shipping on centos5.
p.p.s. I'm just warning golgepapaz what are the requirements.

[killerbot]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

[oBFusCATed]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

Not if you want to treat you customers/users well. Forcing your users to install other compilers is not good.
And after that you'll have to ship wrapper scripts which modify LD_LIBRARY_PATH so the libstdc++ is found and so on. Lots of complications.

Also what about all the users of ubuntu 10/11 or older debians?

[stefanos_]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

Not if you want to treat you customers/users well. Forcing your users to install other compilers is not good.
And after that you'll have to ship wrapper scripts which modify LD_LIBRARY_PATH so the libstdc++ is found and so on. Lots of complications.

Also what about all the users of ubuntu 10/11 or older debians?

@oBFusCATed: Are you suggesting ANSI C in such cases, so you can take the advantage of its portability? If yes, is there an existing project you can recommend? I'm interested to look its code please.