Re: [Geany-devel] C++ Symbols problem
> Cheers > Lex PS my mention on IRC of possible namespace problems as well just turned out to be my typing a brace in the wrong place :-P ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] C++ Symbols problem
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:
templateclass problem;
template<> class problem {
};
template<> class problem {
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
b) at line 3 definition of problem
c) at line 6 definition of problem
Note that these are distinct classes as if the names include ,
and .
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
Re: [Geany-devel] Where have the thirdparty plugins gone?
On Sat, 2012-03-03 at 15:55 +0100, Dominic Hopf wrote: > On Fri, 2012-03-02 at 08:33 +0100, Frank Lanitz wrote: > > BTW: (I think) All other plugins inside the svn > > has been officially deprecated or moved into geany-plugins combined > > plugins project. > > Sounds like it is save to just remove them from the navigation at > http://plugins.geany.org/ then? Well, removed for now. Let me know in case I removed too much, I'll `git revert` it then ;) Best Regards, Dominic -- Dominic Hopf http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: This is a digitally signed message part ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Where have the thirdparty plugins gone?
On Mon, 2012-03-05 at 23:58 +0400, Eugene Arshinov wrote: > That was me who agreed to maintain the Mini-Script plugin. That > plugin is now inside geany-plugins. Also it seems to have a working > README. What should be done to place this README on the site? Hi Eugene, sorry for my late reply. There is nothing to do for you, there is a Cron job running the gencontent.sh [1] every night at 04:05 UTC. The thing with this currently is, that the new geanyminiscript plugin isn't in a tagged release, yet. I've lately changed the behavior of the gencontent.sh to generate the site only from a tagged release, because people were claiming about the consistency with the website and released versions of Geany-Plugins in several threads here on the list. I hope you are fine with waiting for the next Geany-Plugins release until it appears on the website? - Otherwise I will have to give the gencontent.sh script some more love. :) Best Regards, Dominic [1] https://github.com/geany/plugins.geany.org/blob/master/gencontent.sh -- Dominic Hopf http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: This is a digitally signed message part ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Mon, 12 Mar 2012 09:59:45 +1100 Lex Trotman wrote: > Maybe you should contact Matthew, during a conversation we had on IRC > he revealed a prototype for manageing all such limited resources, not > just markers, in a consistent manner. This concerns all plugin developers. @Matthew, can you public the prototype or it's short description on the mailing list, or on another shared resource?.. > I wouldn't expect (for example) GeanyLatex to interfere with my C# > programming. Similarly I wouldn't expect the debugger plugin to try > to work on a language gdb doesn't understand, eg Java. Sounds nice. But for some reason, both Scintilla and Geany use fixed resources, independent of file type. Folding for text files, anyone?.. A per-document allocation, no matter how implemented, also introduces per-document resource exhaustion errors. So we should at least have a policy how such error messages are displayed - they must be both noticable and not too annoying. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usage of plugin_help()
Am 12.03.2012 00:24, schrieb Lex Trotman: > [...] Question is, what do we really want to have behind that function? >>> >>> The delivery format is less important than actually providing help. >> >> I guess that's set. But how would such a thing look like? > > Well, since you are trying to get GP plugins to provide a ReST > formatted readme why not make it a recommendation for a ReST formatted > help which the GP build script can turn into an installed html file. > So the plugin_help() just needs to call utils_open_browser(). > > Use the same css as Geany's manual and get a consistent look and feel. > > As to content, first guess recommended layout: > > How to use > -- > What it does, menu items, keybindings > > Preferences > --- > blah > > How to configure > -- > blah > > The last is only needed if there is configuration beyond the > preferences settings. I like that idea. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
