Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi Adberrahim,


Le 22/04/2012 23:44, Abderrahim Kitouni a écrit :
> FWIW, the current plugin is used by vala as well for indentation, so
> splitting it into 2 plugins (one for language independent stuff like
> indentation, and one for the C/C++ specific stuff that would eventually
> use clang) seems like a fine idea to me.

I'm rather agree with this but I'm afraid it could still be language 
specific. I think vala and C could use the same indentation plugin but 
python needs perhaps something special. Then perhaps we could have a few 
indentation plugins and the language support plugin has just to load the 
right indentation plugin.


> btw, what do you think about the added dependency on clang? Should it be
> optional (and what would remain if it's unavailable?) or should it be
> mandatory?

I would prefer to have it optional and be able to use ctags if it is not 
available. But I don't know if I will do it myself.


> I'm not sure what you mean. IIUC, the symbol listing is currently
> handled by the symbol-db plugin using ctags, do you want to make it so
> that language-support plugins push the symbols to the symbol-db using
> better parsers than ctags?

Yes, it would be a possibility. Currently, I'm annoyed by the fact that 
you parse by example python in the language support plugin using rope 
and in the symbol-db plugin using ctags. I think it would be better to 
do it only one time but I don't know this part that well so perhaps 
there are good arguments to do it two times.

In addition, there are quite a lots of similar code in python and C 
language support plugin.


> and the same for libvala, and btw, I have some code in the Vala plugin
> that tries to get the VALAFLAGS from the project, that might be
> improved.

We will have to do the same with clang. What improvement to you expect 
over reading the project VALAFLAGS? The GEdit plugin is reading a dump 
of make database to get these flags, it could be a bit more precise but 
need a configured project.


> Why? you seem to be separating the language support plugins from parser
> plugins, and I don't see why the language plugins need to call
> symbol-db, they might already have the needed info in memory for things
> like autocompletion.

If possible I think it would be better to have:

* A generic language support plugin providing all necessary GUI part 
(indentation, auto completion) similar to the gcp plugin of gedit code 
assistance plugin.

* Then have the symbol db plugin taking care of the database management 
only.

* And finally have some parsers plugin specific to each language.

But, I don't know if it's possible. The GEdit code assitance plugin, has 
rather a language specific plugin which is using a generic language 
support plugins.

I remember when I have discussed this with Ishan, that it's difficult to 
parse a python code and get all symbols.


> I don't know what is the database used for, but if it is needed for
> listing and/or searching symbols, we'd need to keep it.

I'm agree.


> I don't know, but I think the architecture should take into account the
> other plugins: the Vala plugin is doing something similar using libvala,
> and having a common architecture would be a good idea.

Indeed, but I don't know this code very well.


Regards,

Sébastien