Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC
MortenMacFly:
--- Quote from: yvesdm3000 on December 07, 2015, 02:45:29 pm ---All constructive feedback is welcome.
--- End quote ---
I've added a tiny note on commit:
https://github.com/yvesdm3000/ClangLib/commit/d0d558a1bf5ffe00b3a6dfc4ee816ea6fb48be2a
yvesdm3000:
--- Quote from: MortenMacFly on December 07, 2015, 08:22:57 pm ---
--- Quote from: yvesdm3000 on December 07, 2015, 02:45:29 pm ---All constructive feedback is welcome.
--- End quote ---
I've added a tiny note on commit:
https://github.com/yvesdm3000/ClangLib/commit/d0d558a1bf5ffe00b3a6dfc4ee816ea6fb48be2a
--- End quote ---
I now incorporated your suggestion.
Too bad the tabjump doesn't work on Windows, the way I implemented it is probably a little bit too hackish.
Maybe I should add this to the Scintilla wrapper class instead, so that the other CC implementations can use it too ? It would solve the "hack"-issue too...
The feature allows you to jump to the next parameter of a function that was inserted with CC, using the Tab-key. This also selects the placeholder text so that the user can easily start typing the parameter value.
This works nicely on Linux.
Yves
l_inc:
yvesdm3000
You made a whole bunch of methods public, which rendered the plugin unusable, cause the vector of TUs now works with them as with copyable objects, which results in exceptions (("Illegal copy attempted of TranslationUnit object.")). Btw. the "-ansi" option must be removed, cause it disables many features of C++11.
Another problem is that the plugin works for a single TU only if there are multiple open.
yvesdm3000:
--- Quote from: l_inc on December 08, 2015, 07:57:33 pm ---yvesdm3000
You made a whole bunch of methods public, which rendered the plugin unusable, cause the vector of TUs now works with them as with copyable objects, which results in exceptions (("Illegal copy attempted of TranslationUnit object.")). Btw. the "-ansi" option must be removed, cause it disables many features of C++11.
Another problem is that the plugin works for a single TU only if there are multiple open.
--- End quote ---
Can you be a little bit more specific? Do you use the precompiled version or do you compile it yourself? The error you are complaining about is only enabled when C++11 is enabled so I assume you compile the plugin yourself.
C++11 is not a requrement since that is not what C::B uses... I even don't test it for C++11 since I want to focus on implementing features first and make the changes for C++11 later (it's easier to move from old to new C++). I know there is the move-operator and stuff that is defined away, but currently that is not supposed to be enabled for now. I can even imagine it doesn't work at all because I swap away a TU that is being reparsed, to move it out from under the lock, you get huge congestion otherwise, blocking everything while parsing/reparsing.
For me the plugin does not work with a single TU, it switches TU when the associated document is opened. And I happen to push a change a couple of hours ago that fixes the "Find imlementation" to search across multiple TU's. Obviously those TU's need to be opened first... Code-completion only needs 1 TU. If you want symbols from non-included headers, better include the header then.
Regarding broadening the scope for the "Find implementation" to the full project, that is still a TODO and I think it's better to implement persistency of the internal database first and then do any indexing of all the documents in the project.
I remind you this is only a prerelease and by all means not a final product, although I do use it for my daily main job now.
Yves
l_inc:
yvesdm3000
--- Quote ---Can you be a little bit more specific?
--- End quote ---
Sorry, I was in a hurry. I do indeed compile the plugin. Precompiled versions of CodeBlocks plugins seem to me only good when being part of a distribution. Otherwise their usefulness scope is too limited.
--- Quote ---I even don't test it for C++11 since I want to focus on implementing features first and make the changes for C++11 later
--- End quote ---
Wouldn't you be willing to consider dropping support for C++ older than C++11 at all? C++11 is safer in many ways. E.g. much safer would be to have a vector of unique_ptr's to TUs with enforced move-semantics than having these dirty swap-hacks in a copy-constructor. I see no reason to continue suffering in supporting the older standards. I would even expect the "mysterious crashes" you are talking about in your todo-list to go away after conscientiously switching to C++11.
--- Quote ---I remind you this is only a prerelease and by all means not a final product, although I do use it for my daily main job now.
--- End quote ---
I understand that. I was just shocked to see the commented private replaced with public and the private methods being used outside of the class scope. This made me scared about the project becoming a heap of crutches even before the first release would come out.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version