Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
[Solved] Distracting SymbolBrowser Behaviour
tigerbeard:
Second Test
* Set CC option to OneParserPerProject. It will ask to reparse. Set OK
* Repeat Test1. it should show the expected behaviour
* Enter Project Tab and select project Clangd client
* Switch to Symbol Browser Tab.
* Set Symbol Browser to "Current Projects Symbols".
* Observe Popup : "This feature is not supported in combination with the option "one parser per whole workspace".
If you got the popup there are several ways to get to the correct display. Beside restarting CB switching to FileSymbold and selecting a file in the new project and switching back worked.
* Open naemspace Doxygen
* double click on DoxygenParser class -> header opens. tree is stable
* double click on DoxygenParser ctor -> cpp opens. tree is stable
* Add a space in the open doxygen_parser.h file and press CTRL-S to save
* Obvservation: The tree is refeshed and closed
Expected: The tree is refeshed and remains open
Pecan:
--- Quote from: tigerbeard on January 03, 2024, 01:14:41 pm ---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.
--- End quote ---
I think this is actually working as expected.
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.
I'm guessing this is how the original developer meant it to work. For this reason:
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.
This behavior could be changed by someone with the cohones to modify legacy CC, but that would not include me since a single click solves the problem. If a user does not want to see the bottom tree, just pull the split window slider down.
tigerbeard:
--- Quote from: Pecan on January 08, 2024, 09:14:42 pm ---I think this is actually working as expected.
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.
--- End quote ---
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?
--- Quote from: Pecan on January 08, 2024, 09:14:42 pm ---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.
This behavior could be changed by someone with the cohones to modify legacy CC, but that would not include me
--- End quote ---
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.
--- Quote from: Pecan on January 08, 2024, 09:14:42 pm ---legacy CC
--- End quote ---
I do not want to hijack my own thread but you mentioned that before and I'd be interested why you say that.
I am aware that you are an clang expert. I have to admit that I never used it but I checked the CB wiki and the wikipedia page. It tells me basically its alternative C++ token parser that must run as server process on my pc and it has some Apple history and comes from another compiler suite. I did not see any advantages it would have compared to using the "legacy" system. 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?
Pecan:
--- Quote from: tigerbeard on January 09, 2024, 12:15:46 pm ---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?
--- End quote ---
I now think I'm wrong. When debugging with your second test, I see some problems.
When I went back to the first test, I could cause the liinux problem on windows also. So I'm still working on this.
--- Quote ---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.
--- End quote ---
Here are the routines I'm circling in on:
void ClassBrowser::UpdateClassBrowserView
void NativeParser::OnEditorActivated(EditorBase* editor)
void NativeParser::OnParserEnd(wxCommandEvent& event)
--- Quote ---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.
--- End quote ---
This is the test that convinced me that there was a problem.
I got thrown by the fact that legacy CC (LCC) requires that a file of a newly activated project has to be opened before LCC will fill the Symbols tree. The bottom tree of the split window may have nothing to do with it.
--- Quote ---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?
--- End quote ---
The Clangd_client plugin starts the server in another process for you, communication to CB with pipes. the advantage of the plugins is the support that Clangd provides for parsing code using C++11 onward.
LCC will not be updated to support modern compilers.
To run Clangd_client , you need only install clangd and tell the plugin where it lives.
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. But it also eats up a process running clangd iin the background. LCC may be more useful on slow hardware.
However, since I stole a lot of code from LCC, I'm continuing to work on this problem you've presented here because I want to make sure that Clangd_client plugin is not having LCC like problems with the Symbols Browser.
Thanks for reporting, we'll get it fixed yet. Or know the reason why we cannot fix it.
tigerbeard:
--- Quote from: Pecan on January 09, 2024, 08:28:10 pm ---Here are the routines I'm circling in on:
void ClassBrowser::UpdateClassBrowserView
void NativeParser::OnEditorActivated(EditorBase* editor)
void NativeParser::OnParserEnd(wxCommandEvent& event)
--- End quote ---
Great that is really helpful. I'll have a look there.
--- Quote from: Pecan on January 09, 2024, 08:28:10 pm ---LCC will not be updated to support modern compilers.
--- End quote ---
You mean like LLVM or does that include newer gcc versions?
--- Quote from: Pecan on January 09, 2024, 08:28:10 pm ---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.
--- End quote ---
interesting. That might be worth checking out...
--- Quote from: Pecan on January 09, 2024, 08:28:10 pm ---Clangd_client plugin is not having LCC like problems with the Symbols Browser.
--- End quote ---
I wondered whether or not you would have and own symbol broswer for the plugin.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version