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 <[email protected]> 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 >>> [email protected] >>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >> >> >> _______________________________________________ >> Geany-devel mailing list >> [email protected] >> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >> > _______________________________________________ > Geany-devel mailing list > [email protected] > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
