Hi All,
There is a problem with symbols in some C++ programs which causes some class members to appear and disappear or move in the sidebar. Needless to say this is *very* distracting.
The minimal program to demonstrate this is:
template<bool b>class problem;
template<> class problem<false> { };
template<> class problem<true> { int i_change; };
The member i_change changes each time the symbols pane is updated, correctly showing as part of the class at line 6, then part of the class at line 3, then disappearing, then back to the class at line 6 etc.
In C++ this program has three class names:
a) at line 1 declaration of problem<bool> b) at line 3 definition of problem<false> c) at line 6 definition of problem<true>
Note that these are distinct classes as if the names include <bool>, <true> and <false>.
But neither symbols.c or the tagmanager parser includes the template parameters in the name, instead showing both of the classes at line 3 and 6 as "problem".
Discussion with Colomban on IRC indicated that this may be confusing the symbol update algorithm. Forcing a complete re-generation of the symbols did indeed stabilise the sidebar.
I think that the problem is due to update_tree_tags() identifying the parent of i_change just by name so it can't tell if line 3 or line 6 (or possibly line 1) is the parent.
If i_change is shown in the symbol tree as part of the class at line 6 then it will be in the parent_tags hash with parent of "problem". If this is taken as "problem"of line 3 as parent, it will delete it from the class at line 6 in pass 1 and as i_change is still in the tags list will add it to the class at line 3 since thats what the parent_tags hash says is its parent.
On the next symbol update, since what it thinks is the parent of i_change (the class at line 3) does not in fact have i_change as a member, it will be deleted from the tree and the tags list, so it isn't added again in pass 2.
On the next symbol update i_change is not in the tree so it isn't in the parent_tags hash so it is added where the tags list says is the correct place.
If the order of the definitions at line 3 and 6 are reversed i_change just alternates on and off, suggesting that it isn't the first definition of the symbol "problem" that is the one found.
At least I think this is the mechanism?
Other than the hack to re-create the whole table each time, I'm not sure how to cure it without distinguishing the three class names, and that means modifying tagmanager/c.c (shudder).
Cheers Lex
Hi All,
So that I don't look unreasonable for criticising just Geany I investigated what many other IDEs do with the same source, basically working my way through the wikipedia C++ IDEs list (at least the open ones we might, erm, share code from, and that would run on my machine without changes to its configuration).
The results are sumarised below:
Anjuta, symbols pane wrong - repeated members on both problems<true> and problems<false>, autocomplete failed, none offered
Code::Blocks and Codelite both failed to install due to wxWidgets dependency problems.
Eclipse CDT, symbols pane CORRECT, autocomplete works but ignores private/public access restrictions (minor issue)
Emacs, no symbol pane, autocomplete saw second definition only, change order and change the offered autocomplete.
Geany, symbols pane cycles members as previously described, autocomplete-ly crap
Gnat programming Studio, symbols pane didn't work, autocomplete didn't work, program was so slow it was unusable so test was cut short
Kdevelop could not install because I wouldn't let it install most of KDE as well :(
Monodevelop, symbols pane didn't work at all, autocomplete didn't work at all (help didn't work so I couldn't figure out why)
Netbeans, symbols pane CORRECT, autocomplete CORRECT including adhering to private/public access restrictions.
Qt creator installed and ran but would not create even a plain C++ project without full qt install >1GB which I won't do :(
And Matthew kindly tried xcode for me, symbols pane correct, autocomplete did not work
Unfortunately that leaves Geany as the worst of those that worked at all :(
In fact it would even be better if . and -> autocomplete was turned off for C++ rather than offering complete crap (and that isn't related to this particular file unfortunately).
As my brain is now drained from all those, I leave it to someone else to suggest some idea of a path forward.
Cheers Lex
Le 16/03/2012 11:30, Lex Trotman a écrit :
Hi All,
Hey,
I haven't had the time yet to try to fix the sidebar bug, but...
So that I don't look unreasonable for criticising just Geany I
Sweet :p
[...]
In fact it would even be better if . and -> autocomplete was turned off for C++ rather than offering complete crap (and that isn't related to this particular file unfortunately).
Try the attached patch maybe. It's not really polished and I haven't published it because it's not really "the right fix", but if scope completion is *that* broken with C++ maybe it's worth committing this at least as an interim solution 'till I manage to get another tagmanager impl working [1]. That patch is a reimpl of the feature that at least I can understand (no TM stuff, heh), and it shows quite good results at least for C (and smaaaaaaal C++ tests).
Cheers, Colomban
[1] It's somewhat on the way, but it's far from being trivial work and I have/had some non-geany stuff lately, so I wasn't able to work on this that much
As my brain is now drained from all those, I leave it to someone else to suggest some idea of a path forward.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 17/03/2012 15:28, Colomban Wendling a écrit :
Le 16/03/2012 11:30, Lex Trotman a écrit :
Hi All,
Hey,
I haven't had the time yet to try to fix the sidebar bug, but...
So that I don't look unreasonable for criticising just Geany I
Sweet :p
[...]
In fact it would even be better if . and -> autocomplete was turned off for C++ rather than offering complete crap (and that isn't related to this particular file unfortunately).
Try the attached patch maybe.
Hum, it'd be easier with an attachment. Here it is.
It's not really polished and I haven't published it because it's not really "the right fix", but if scope completion is *that* broken with C++ maybe it's worth committing this at least as an interim solution 'till I manage to get another tagmanager impl working [1]. That patch is a reimpl of the feature that at least I can understand (no TM stuff, heh), and it shows quite good results at least for C (and smaaaaaaal C++ tests).
Cheers, Colomban
[1] It's somewhat on the way, but it's far from being trivial work and I have/had some non-geany stuff lately, so I wasn't able to work on this that much
As my brain is now drained from all those, I leave it to someone else to suggest some idea of a path forward.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 13/03/2012 01:48, Lex Trotman a écrit :
Hi All,
Hey!
Here's an initial patch that fixes the issue by better handling of true duplicate tags. It's not necessarily the better fix for the issue, where maybe having the template type info would be better, but it is more generic since it would handle any duplicate.
It's not much tested, but have fun :)
Cheers, Colomban
There is a problem with symbols in some C++ programs which causes some class members to appear and disappear or move in the sidebar. Needless to say this is *very* distracting.
The minimal program to demonstrate this is:
template<bool b>class problem;
template<> class problem<false> { };
template<> class problem<true> { int i_change; };
The member i_change changes each time the symbols pane is updated, correctly showing as part of the class at line 6, then part of the class at line 3, then disappearing, then back to the class at line 6 etc.
In C++ this program has three class names:
a) at line 1 declaration of problem<bool> b) at line 3 definition of problem<false> c) at line 6 definition of problem<true>
Note that these are distinct classes as if the names include <bool>, <true> and <false>.
But neither symbols.c or the tagmanager parser includes the template parameters in the name, instead showing both of the classes at line 3 and 6 as "problem".
Discussion with Colomban on IRC indicated that this may be confusing the symbol update algorithm. Forcing a complete re-generation of the symbols did indeed stabilise the sidebar.
I think that the problem is due to update_tree_tags() identifying the parent of i_change just by name so it can't tell if line 3 or line 6 (or possibly line 1) is the parent.
If i_change is shown in the symbol tree as part of the class at line 6 then it will be in the parent_tags hash with parent of "problem". If this is taken as "problem"of line 3 as parent, it will delete it from the class at line 6 in pass 1 and as i_change is still in the tags list will add it to the class at line 3 since thats what the parent_tags hash says is its parent.
On the next symbol update, since what it thinks is the parent of i_change (the class at line 3) does not in fact have i_change as a member, it will be deleted from the tree and the tags list, so it isn't added again in pass 2.
On the next symbol update i_change is not in the tree so it isn't in the parent_tags hash so it is added where the tags list says is the correct place.
If the order of the definitions at line 3 and 6 are reversed i_change just alternates on and off, suggesting that it isn't the first definition of the symbol "problem" that is the one found.
At least I think this is the mechanism?
Other than the hack to re-create the whole table each time, I'm not sure how to cure it without distinguishing the three class names, and that means modifying tagmanager/c.c (shudder).
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Colomban,
I used both patches all afternoon with no visible problems. They seem to work as advertised. Will keep using, thanks.
Cheers Lex
On 18 March 2012 08:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 13/03/2012 01:48, Lex Trotman a écrit :
Hi All,
Hey!
Here's an initial patch that fixes the issue by better handling of true duplicate tags. It's not necessarily the better fix for the issue, where maybe having the template type info would be better, but it is more generic since it would handle any duplicate.
It's not much tested, but have fun :)
Cheers, Colomban
There is a problem with symbols in some C++ programs which causes some class members to appear and disappear or move in the sidebar. Needless to say this is *very* distracting.
The minimal program to demonstrate this is:
template<bool b>class problem;
template<> class problem<false> { };
template<> class problem<true> { int i_change; };
The member i_change changes each time the symbols pane is updated, correctly showing as part of the class at line 6, then part of the class at line 3, then disappearing, then back to the class at line 6 etc.
In C++ this program has three class names:
a) at line 1 declaration of problem<bool> b) at line 3 definition of problem<false> c) at line 6 definition of problem<true>
Note that these are distinct classes as if the names include <bool>, <true> and <false>.
But neither symbols.c or the tagmanager parser includes the template parameters in the name, instead showing both of the classes at line 3 and 6 as "problem".
Discussion with Colomban on IRC indicated that this may be confusing the symbol update algorithm. Forcing a complete re-generation of the symbols did indeed stabilise the sidebar.
I think that the problem is due to update_tree_tags() identifying the parent of i_change just by name so it can't tell if line 3 or line 6 (or possibly line 1) is the parent.
If i_change is shown in the symbol tree as part of the class at line 6 then it will be in the parent_tags hash with parent of "problem". If this is taken as "problem"of line 3 as parent, it will delete it from the class at line 6 in pass 1 and as i_change is still in the tags list will add it to the class at line 3 since thats what the parent_tags hash says is its parent.
On the next symbol update, since what it thinks is the parent of i_change (the class at line 3) does not in fact have i_change as a member, it will be deleted from the tree and the tags list, so it isn't added again in pass 2.
On the next symbol update i_change is not in the tree so it isn't in the parent_tags hash so it is added where the tags list says is the correct place.
If the order of the definitions at line 3 and 6 are reversed i_change just alternates on and off, suggesting that it isn't the first definition of the symbol "problem" that is the one found.
At least I think this is the mechanism?
Other than the hack to re-create the whole table each time, I'm not sure how to cure it without distinguishing the three class names, and that means modifying tagmanager/c.c (shudder).
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 18/03/2012 10:59, Lex Trotman a écrit :
Hi Colomban,
I used both patches all afternoon with no visible problems. They seem to work as advertised. Will keep using, thanks.
Great then :) I now have committed the sidebar fixes.
Cheers, Colomban
Cheers Lex
On 18 March 2012 08:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 13/03/2012 01:48, Lex Trotman a écrit :
Hi All,
Hey!
Here's an initial patch that fixes the issue by better handling of true duplicate tags. It's not necessarily the better fix for the issue, where maybe having the template type info would be better, but it is more generic since it would handle any duplicate.
It's not much tested, but have fun :)
Cheers, Colomban
There is a problem with symbols in some C++ programs which causes some class members to appear and disappear or move in the sidebar. Needless to say this is *very* distracting.
The minimal program to demonstrate this is:
template<bool b>class problem;
template<> class problem<false> { };
template<> class problem<true> { int i_change; };
The member i_change changes each time the symbols pane is updated, correctly showing as part of the class at line 6, then part of the class at line 3, then disappearing, then back to the class at line 6 etc.
In C++ this program has three class names:
a) at line 1 declaration of problem<bool> b) at line 3 definition of problem<false> c) at line 6 definition of problem<true>
Note that these are distinct classes as if the names include <bool>, <true> and <false>.
But neither symbols.c or the tagmanager parser includes the template parameters in the name, instead showing both of the classes at line 3 and 6 as "problem".
Discussion with Colomban on IRC indicated that this may be confusing the symbol update algorithm. Forcing a complete re-generation of the symbols did indeed stabilise the sidebar.
I think that the problem is due to update_tree_tags() identifying the parent of i_change just by name so it can't tell if line 3 or line 6 (or possibly line 1) is the parent.
If i_change is shown in the symbol tree as part of the class at line 6 then it will be in the parent_tags hash with parent of "problem". If this is taken as "problem"of line 3 as parent, it will delete it from the class at line 6 in pass 1 and as i_change is still in the tags list will add it to the class at line 3 since thats what the parent_tags hash says is its parent.
On the next symbol update, since what it thinks is the parent of i_change (the class at line 3) does not in fact have i_change as a member, it will be deleted from the tree and the tags list, so it isn't added again in pass 2.
On the next symbol update i_change is not in the tree so it isn't in the parent_tags hash so it is added where the tags list says is the correct place.
If the order of the definitions at line 3 and 6 are reversed i_change just alternates on and off, suggesting that it isn't the first definition of the symbol "problem" that is the one found.
At least I think this is the mechanism?
Other than the hack to re-create the whole table each time, I'm not sure how to cure it without distinguishing the three class names, and that means modifying tagmanager/c.c (shudder).
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel