Clang CC

[yvesdm3000]

Oh, one more thing I forgot about. I had to add:

Code

#include <iostream>

to 'clangplugin.cpp' and 'translationunit.cpp' to build the plugin. I don't know why iostream were missing in those 2 files initially.

Erm... why do we need iostream?  Logging/debug logging should be directed through C::B's log manager.

What do you think? I'll submit patches using the name 'Clang Code Completion' under color settings in 'settings->environment->colors'.

No problem for me as long as Alpha0010 and the other nice C::B guys approve.

I believe the main CC plugin already registers some colors; if possible, reuse those first.

For the logging it's just debugging stuff, especially with threads I tend to be carefull and a simple fprintf is often easy. Those should be removed at a later stage in a cleanup when everything works as expected. Intended logging should go to the log manager.

For the colours, all I have seen is that the plugin simply returns the codecompletion data back to C::B so colouring should be handled on that level, except for maybe the HTML it returns for documentation.

Yves

[scarphin]

Erm... why do we need iostream?  Logging/debug logging should be directed through C::B's log manager.

I had to include them because the compiler were spitting 'cout doesn't belong to namespace std' kind of errors. I think yvesdm3000 made it clear.

I believe the main CC plugin already registers some colors; if possible, reuse those first.

As you wish. I also prefer to reuse the same colors but my reasoning was that the clang cc uses a different color for errors while the built-in cc doesn't have a designated color for that which might introduce color entries that are not used by some plugins. Also people may opt for different syntax highlighting for different languages making cc plugins for different languages less responsive in terms of colors. I think at least cc plugins for different languages should define their own colors.

@obfuscated: Stated above.

[oBFusCATed]

Also people may opt for different syntax highlighting for different languages making cc plugins for different languages less responsive in terms of colors. I think at least cc plugins for different languages should define their own colors.

If you ask me this is not a good idea.
Generally I try to make all languages look roughly the same.
What error color are we talking about, because I've not tried this plugin yet?

[scarphin]

I try to make all languages look exactly the same but that doesn't rule out other combinations users may provide.

As for the errors I provided 2 screenshots in one of my previous posts.

[oBFusCATed]

I guess I've misunderstood you, because I thought that you're talking about some colours for errors. Ignore.

[yvesdm3000]

I guess I've misunderstood you, because I thought that you're talking about some colours for errors. Ignore.

Since the clang-plugin uses a compiler, it has warnings and errors on his own. These text-strings are inlined on the line it occurs. I'm unsure if C::B has generic colours for this.

In the end the plugin should also have a dialog to toggle these features on or off, and also some options to add or filter-out compiler options with some good defaults of options it doesn't know about.

-Yves

[yvesdm3000]

I added some commits that addresses crashes. Seems to work OK now for me on very big files, but I had to add some bigger timeouts which makes it less smooth. :-(

Yves

[yvesdm3000]

Performed a new push to GitHub addressing various usability issues and moved to using cb BackgroundThread and its job queue. I now use it on a daily basis for my professional coding and deal with cpp files with more then 15.000 lines. I can't really say it's smooth on those big files since reparsing takes a long time, but it doesn't prohibit me in typing/editing, it only results in less or delayed code completion results.

Yves

[l_inc]

yvesdm3000
I had some difficulties compiling this plugin, but it's such a pleasure to use. Is there any chance to have it in codeblocks-contrib anytime soon? I mean the standard CC plugin is nothing but a source of infinite frustration.

[yvesdm3000]

Nice to see feedback. I know it's probably a bit difficult to compile, mostly because my env is not very typical so I simply don't check in my cbp file. I think you only need to fix compile options for wx and c::b ?

It's on my list of todo's, but not at the top.

More tasks to do: the class&method toolbar, goto declaration/implementation context menus and something that replaces cscope.

-Yves

[ollydbg]

It would be best if you can release some prebuild binaries of this package, I remember Alpha has released such one along with the nightly build. So that people can easily test this plugin.

More tasks to do: the class&method toolbar, goto declaration/implementation context menus and something that replaces cscope.
-Yves

The current goto declaration/implementation is supplied by the build-in codecompletion plugin.

yvesdm3000
I had some difficulties compiling this plugin, but it's such a pleasure to use. Is there any chance to have it in codeblocks-contrib anytime soon? I mean the standard CC plugin is nothing but a source of infinite frustration.

The standard CC is still maintained by some people, but it is hard to parse the template or C++11 new feature related code.

[scarphin]

Attached patch makes the documentation colors configurable using the environment color settings. The syntax highlight colors inside the document still needs work to match the users syntax highlighting colors though. Btw clang's documentation parser doesn't seem to be as good as the built-in cc plugin's, or is it?

I'm experiencing a misbehavior with the  completion. When I complete the keyword 'while' for example, I get something like:

Code

while(/*! condition !*/){
}

Is it the clang itself that completes the code like this? Can this behavior be disabled?

[scarphin]

Forgot to tell that the 'Top' link at the bottom of the documentation window doesn't work for some reason.

[l_inc]

ollydbg

The standard CC is still maintained by some people, but it is hard to parse the template or C++11 new feature related code.

It has problems with all sorts of other stuff not related to C++11 (like this issue). I know it's a huge piece of work, but it has just never functioned properly for me with anything beyond helloworlds, and I'm very sorry about it. Even the plain notepad++ way of suggesting whatever it sees in the document without any language parsing is more helpful. Btw. notepad++ has more features working better, but it's a subject for a different topic.

yvesdm3000

More tasks to do: the class&method toolbar, goto declaration/implementation context menus and something that replaces cscope.

If you accept feature suggestions, then I'd prefer to have context dependent syntax highlighting. Current highlighting schemes are plain based on a set of keywords. I'd like the highlighting to be able to differentiate between functions, variables, class names, preprocessor constants etc., which requires support of a syntax parsing plugin.

Another feature is to provide suggestions in a relevance-based order. I.e. when passing arguments to a function, the first suggestion should be a local variable name or an argument of a currently edited function that has the type most compatible with the currently passed argument, and further suggestions should include other castable identifiers in order of how forceful the casting should be.

These two would make it close to the level of VisualAssistX.

[ollydbg]

ollydbg

The standard CC is still maintained by some people, but it is hard to parse the template or C++11 new feature related code.

It has problems with all sorts of other stuff not related to C++11 (like this issue).

I'd like to help on this issue.
Is the test code you supplied only works under Linux system?
I have only Windows system at hand.
The native codecompletion is not that bad as I see.

yvesdm3000

More tasks to do: the class&method toolbar, goto declaration/implementation context menus and something that replaces cscope.

If you accept feature suggestions, then I'd prefer to have context dependent syntax highlighting. Current highlighting schemes are plain based on a set of keywords. I'd like the highlighting to be able to differentiate between functions, variables, class names, preprocessor constants etc., which requires support of a syntax parsing plugin.

Another feature is to provide suggestions in a relevance-based order. I.e. when passing arguments to a function, the first suggestion should be a local variable name or an argument of a currently edited function that has the type most compatible with the currently passed argument, and further suggestions should include other castable identifiers in order of how forceful the casting should be.

These two would make it close to the level of VisualAssistX.

You may look at this plugin: Semantic highlight which also uses clang.