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