Which code completion plugin are you using?
The legacy CodeCompletion or the Clangd_client?
...
BrowseTracker
ToolsPlus
SpellChecker
CodeCompletion
cbDragScroll
EditorConfig
SmartIndentHDL
...
Thanks, I'll see if I can recreate the situation and figure it out.Which code completion plugin are you using?
The legacy CodeCompletion or the Clangd_client?
No I am not using clangd nor have I configured it (ManagePlugins shows it as disabled). The CodeCompletion is Version 1.0 and enabled.
Here is it in the log.Code...
BrowseTracker
ToolsPlus
SpellChecker
CodeCompletion
cbDragScroll
EditorConfig
SmartIndentHDL
...
Thats very kind, thanks.
I have a test using the workspace trunk/src/CodeBlocks_wx30-unix.workspace
First Test
- Set Settings/Editor/CC/CCParser/UseOneParserForWholeWorkspace
- Set Symbol Browser to "Current Projects Symbols"
- Make sure no files are open in the editor
- Activate Project wxSmith/ContribItems
- Switch to symbol Browser
- Open a class in the tree, e.g. wxsAxis and double clikc on the constructor
- Obvservation: The file is opened, and the tree is refeshed and closed
Expected: The file is opened, and the tree remains open and wxAxis ctor is selected.
I think this is actually working as expected.Thanks that you took time to test it. A great tip to just move down the split window (I found that mode hard to use). It seems that on my systems the effect is the same with the bottom tree mode enabled. So maybe there is an additional factor I need to find. Or did you test under Windows?
For the tree to remain stable after the user selects an item, "Display bottom tree" option has to be selected from the tree root context menu.
The code checks for "Display bottom tree" option enabled to determine whether to update the tree to the next project of the workspace, or leave the tree as is.I would like to have a go, but looking through the CC code bought me nowhere yet, so I need to debug myself into the issue. The problem is that bebugging CB on my computers is really slow (5sec+ per step). So it would help me to know which CC function did the check you described above. Maybe from there I could reverse engineer the system and understand the the problem.
This behavior could be changed by someone with the cohones to modify legacy CC, but that would not include me
legacy CCI do not want to hijack my own thread but you mentioned that before and I'd be interested why you say that.
Thanks that you took time to test it. A great tip to just move down the split window (I found that mode hard to use). It seems that on my systems the effect is the same with the bottom tree mode enabled. So maybe there is an additional factor I need to find. Or did you test under Windows?
I would like to have a go, but looking through the CC code bought me nowhere yet, so I need to debug myself into the issue. The problem is that bebugging CB on my computers is really slow (5sec+ per step). So it would help me to know which CC function did the check you described above. Maybe from there I could reverse engineer the system and understand the the problem.
Would you mind to check the other test as well?
The second issue is more annoying part because I do not have a workaround for it yet.
From what I read I only know the disadvantages like another tool to track, configure and maintain, separate installiation on every system, maybe even starting the server before running CB. Unfortunately I do not know any benefit compared to my current "legacy CC" when I am not planning to change the gcc compilers?
Here are the routines I'm circling in on:Great that is really helpful. I'll have a look there.
void ClassBrowser::UpdateClassBrowserView
void NativeParser::OnEditorActivated(EditorBase* editor)
void NativeParser::OnParserEnd(wxCommandEvent& event)
LCC will not be updated to support modern compilers.You mean like LLVM or does that include newer gcc versions?
clangd , itself, uses the parsing stage of your compiler to mark errors w/o having to compile the code. It's much faster to create clean code that way.interesting. That might be worth checking out...
Clangd_client plugin is not having LCC like problems with the Symbols Browser.I wondered whether or not you would have and own symbol broswer for the plugin.
LCC will not be updated to support modern compilers.
You mean like LLVM or does that include newer gcc versions?I mean that LCC will not be updated to support any compiler.
Tell us what wxWidgets version you're using on linux.Have added the info to the ticket.
Please also see: https://sourceforge.net/p/codeblocks/tickets #1444
clangd takes care of that for us. There are also many clangd extensions that we haven't even explored yet. such as suggested fixes while the user is editing (codeActions) and code snippet suggestions while editing.Cool, thanks that good to know.
Solved by a code fix for next nightly by @pecan, thanks a lot!
And there is an information for the issue from Test1: (Symbol Tree when switching between projects):
- When changing projects in the "Project" tab you must open any code file from the new project before switching to the "Symbols" tab. I that is done the symbold browser tree will be re-parsed with the correct project. It needs at least one open file from the project.
I will mark the thread closed
void ClassBrowserBuilderThread::FillGUITree(bool top)
{
CCTree* localTree = top ? m_CCTreeTop : m_CCTreeBottom;
... ... ... ... ... code snipped out ... ... ... ...
CCTreeItem* sourceRoot = localTree->GetRootItem();
if (sourceRoot)
{
m_Parent->CallAfter(&ClassBrowser::TreeOperation, ClassBrowser::OpAddRoot, sourceRoot);
AddItemChildrenToGuiTree(localTree, sourceRoot, true);
m_Parent->CallAfter(&ClassBrowser::TreeOperation, top ? ClassBrowser::OpExpandRoot : ClassBrowser::OpExpandAll, nullptr);
}
... ... ... ... ... code snipped out ... .. .. ... .. .. .. ..
}
I wrote that code three years ago, but I have forgotten the details.
CallAfter() is executed in call order (it uses the event queue), but it is possible for a second call to execute while the first is still running. Probably a mutex in ClassBrowser::TreeOperation() fixes this, or waiting for a "finished" flag after each call to CallAfter().
Give it a try, beat up on it,and let us know how it goes.
Using svn13436, if I open C::B workspace, wait for CC to complete and close the program then codeblocks.exe still shows in the task manager (tested on MSW).
I have detected this after compiling svn13437: executing update32.bat shows a lot of "file in use" errors.
EDIT: nightly 13430 works OK, nightly 13434 fails. This leaves 13432 as the suspect, probably the thread is waiting for a semaphore.
Using svn13436, if I open C::B workspace, wait for CC to complete and close the program then codeblocks.exe still shows in the task manager (tested on MSW).
I have detected this after compiling svn13437: executing update32.bat shows a lot of "file in use" errors.
EDIT: nightly 13430 works OK, nightly 13434 fails. This leaves 13432 as the suspect, probably the thread is waiting for a semaphore.