Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: Loaden on April 21, 2010, 06:11:09 pm
-
In the #include statement:
When entering the #include <xxxx.h| , auto add the ending matching bracket.
As we know, if include a file, like this:
#include "someheader.h
Then, the CC tip's will show "someheader.h" in the Tip Window.
But when we selected it, it's only change to:
#include "someheader.h // HERE, lose a " or >
If we apply this patch, it's can auto completion the matching brackets.
Like this:
#include "someheader.h"
OR
#include <someheader.h>
EDIT: fix, when type some char, it will failed.
[attachment deleted by admin]
-
Fix a bug, now it will works well.
-
Although I didn't try the patch out, this would indeed be nice. Question when the closing "> is added, I assume the cursor is behind it so I don't 'enter' the closing "> to the next line ?
I was wondering what you and others think of this (some of my personal irritations ;-) ).
I typically structure a project like this :
Project-Dir with the following subdirs :
* Project (contains the cbp file)
* src (contains *.cpp and .h[that don't need to be exported]
* inc (contains *h[that are to be exported, typical use : when the project is a static lib or dll]
Use case 1 :
I am working on a file in the src dir, when I want to include a header file it gives them to me as "../src/header.h". This is correct but I like it to be normalized/reduced --> ../src is where I am at the moment, so I just want "header.h"
Use case 2 :
I added for example the inc directory of another component to the list of include/search directories.
I want to include in a source file in the src directory of my current project a header from that other component.
Not even 1 header file from the added include directory shows up. It would be nice those would pop up to.
Use case 3 :
In the ultimate case when I start an include with < , I would like to see the C/C++ headers too in the list.
I have type already so many times vector, string, iostream, .... ;-)
What do you guys think ?
-
About Use case 1 ~ 3:
Hi, killerbot, I need check the code, but now, i can't be sure it.
I will trying.
-
Question when the closing "> is added, I assume the cursor is behind it so I don't 'enter' the closing "> to the next line ?
Yes, if completion the right brace, the caret is here:
#include <some.h>|
-
Use case 3 :
In the ultimate case when I start an include with < , I would like to see the C/C++ headers too in the list.
I have type already so many times vector, string, iostream, .... Wink
I have a think for this for a long time , just not figure out a good way to implement it. :wink:
-
For 3: Is there a way to get all automatic include paths?
If there is we can scan this paths and cache the result, after some time we can scan again.
Another way is to hook the folders and wait for changes.
-
For 3: Is there a way to get all automatic include paths?
If there is we can scan this paths and cache the result, after some time we can scan again.
Another way is to hook the folders and wait for changes.
For GCC we go hunt for them for the CC, otherwise even something like right clicking on include <string> to open the string header didn't work.
-
Use case 1 :
I am working on a file in the src dir, when I want to include a header file it gives them to me as "../src/header.h". This is correct but I like it to be normalized/reduced --> ../src is where I am at the moment, so I just want "header.h"
Use case 2 :
I added for example the inc directory of another component to the list of include/search directories.
I want to include in a source file in the src directory of my current project a header from that other component.
Not even 1 header file from the added include directory shows up. It would be nice those would pop up to.
Hi, killerbot, I make a patch for do this.
Welcome for test.
The patch based cc branch.
-
this sounds great, could you think you can have a patch for trunk ?
by the way : any idea when another merge round from cc_branch to trunk might happen ?
-
The patch based cc branch.
...and applied there.
by the way : any idea when another merge round from cc_branch to trunk might happen ?
Depends on how well we do testing of this branch. Everybody can contribute by doing so and making tests. Basically the CC branch is very well lined-up with trunk so you are not going to miss any features if you simply switch to this branch.
What about a second nightly? - One for trunk and one for the branch... probably not always... but from time-to-time?!
-
Use case 3 :
In the ultimate case when I start an include with < , I would like to see the C/C++ headers too in the list.
I have type already so many times vector, string, iostream, .... ;-)
support system headers now. :lol:
Based CC Branch too.
Sorry, I am not using trunk, but only cc branch.
-
time to jump towards the cc branch for me then.
One question related to the branching. I would keep both branches on my laptop. And depending on what to use for the moment, I would issued the make install of the branch of interest.
Could there be any conflicts of each time make install on top of the previous one [by the way : what's the clean for make install ? is it make distclean ?]
-
Use case 3 :
In the ultimate case when I start an include with < , I would like to see the C/C++ headers too in the list.
I have type already so many times vector, string, iostream, .... ;-)
support system headers now. :lol:
Based CC Branch too.
Sorry, I am not using trunk, but only cc branch.
@Martin : could you apply this one too to the cc branch ?
-
what's the clean for make install ? is it make distclean ?
-
@Martin : could you apply this one too to the cc branch ?
Done. But it's untested (from my point of view).
-
But this is not very robust way of uninstalling software (you should have the original sources/build system).
killerbot:
The best way is to learn how to make packages from source for your distro (gentoo and arch are pretty easy with svn software. I don't know how hard it is in deb and rpm based distros, but it shouldn't be too hard :) )
-
checkinstall (http://www.asic-linux.com.mx/~izto/checkinstall/index.php) is the package to look for (at least for test installs, normally not for real packages).
It monitors the installation and creates Slackware, rpm or debian packages.
And "make uninstall" should work, and yes it should be used from original sources of course.
-
well packages are a bit too much, when building from source : make && make install, then make uninstall should do the trick, I guess as suggested by Jens.
By the way, currently I checked out the cc branch with just read permissions, anyone have it open with write permissions --> merge from trunk please because cc branch does not build (wxMedia issue ...).
-
I tested it using ArchLinux, it still works well, but prompt header slower rate of more than XP. :(
-
Here is another patch, for support preprocessor completion.
And improve system headers completion.
-
wauw, this is really looking very great :P
-
it however doesn't work for some preprocessor stuff for me.
I want to type : #include ......
when I type the '#' I already get code completion suggestions, but include is not one of them.
-
it however doesn't work for some preprocessor stuff for me.
I want to type : #include ......
when I type the '#' I already get code completion suggestions, but include is not one of them.
Fixed!
-
I can confirm this is fixed, but now I don't get any include files anymore.
1) I type #in --> complete to include
2) then I type either < or " --> once again I get the list of preprocessor completions (define, elif, include , ....)
-
1) I type #in --> complete to include
2) then I type either < or " --> once again I get the list of preprocessor completions (define, elif, include , ....)
Harhar... same here. :-)
-
1) I type #in --> complete to include
2) then I type either < or " --> once again I get the list of preprocessor completions (define, elif, include , ....)
Harhar... same here. :-)
Sorry, I was careless.
Fixed again.
-
I can confirm it now works, and also right click on an include to open it, now works again (just before most of them were 'not found').