Re: [ jEdit-devel ] Code Book Plugin

[Shlomy R. <sre...@gm...>]

So this means that the plugin won't complete methods and instance
variables of a class if accessed by a class object?
e.g. what will it do here, which is the most common case:
void f() {
  SomeClass obj = new SomeClass();
  obj.<-- caret is here, invoking completion action

Shlomy

On Tue, Jan 12, 2010 at 12:37 AM, Damien Radtke <dam...@gm...> wrote:
> Instance variables aren't fully supported yet as I've been unsure about how
> best to parse and store that information (reading SideKick's parsed data is
> my current approach, but if CtagsInterface can store a variable's name and
> class then I'll consider using that).
> The idea behind the actual completion itself is fairly straightforward.
> There are several scenarios. If the character at the cursor is a dot, the
> word behind that dot is searched for in the parsed data (a number of .dat
> files stored in the plugin's home directory), and if found, static
> members/methods are displayed. If it's not found, instance variables will be
> searched (again, not fully implemented). If the character at the cursor is
> an opening parenthese, then constructors are displayed. If neither one, then
> if the word at the cursor is found its package is inserted before the word.
> Regarding context, I am considering adding an extension for ProjectViewer in
> order to support an occasional hidden call to javadoc, which would generate
> javadoc files for the project, and then those would be parsed and stored in
> a separate location. Yet another feature that is on my to-do list.
> As you can tell, this plugin so far is heavily dependent on a very rigid and
> systematic documentation structure per programming language, which is why
> Java works so well for this. I don't think Python will be too hard (I will
> look into the pydoc tool), but those are the only documentation tools I know
> of. Do you happen to know of any for C/C++? If nothing else I will add
> support to parse header files, but a full-fledged documentation tool would
> be preferred, if it exists.
> The completion of method parameters is something I've been looking into
> improving (as of right now, the default value given in the API is inserted),
> so I will look into using SuperAbbrevs for that, and I can also try moving
> the description from the statusbar to a tooltip.