Re: [gedit-list] Plugins

[Jesse van den Kieboom <jesse icecrew nl>]

Sorry Paolo, made the same mistake :(

Op ma, 24-04-2006 te 17:09 +0200, schreef Paolo Borelli:
> >>> - The project plugin, I think there were about three persons working on
> >>> something, but there isn't really anything done as far as I know. I
> >>> think a good project plugin can be very useful for other plugins as well
> >>> because it allows for applying things to all files in the project
> >>> (thinking about cvs/svn plugin or formatting plugin)
> >>>
> >>>   
> >>>       
> >> A project plugin sounds all nice and fine. Interdependent plugins is a 
> >> can of worms I am not really eager to open, so IMHO the longer we resist 
> >> this temptation, the better.
> >>     
> >
> > I disagree. I think we should tackle this problem sooner then later.
> > I've argued before that I'd like to have inter-plugin communication
> > possibilities. Python plugins don't need any changes to be able to make
> > use of each other. I understand that dependencies involves a lot more
> > than just letting one plugin call stuff at another plugin, but in my
> > opinion a lot of plugins can make use of the project information in a
> > project plugin.
> >
> >   
> 
> My gripe with this is that it could be easily abused. I'd rather see a
> bottom up approach:
> - what are the specific use cases?

The ones I can think of right now are access to project information in
the project plugin. Access to the terminal plugin to execute shell
stuff.

> - does this use cases really need cross-plugin comunication?  Would
> they be better solved by putting a widget in the core and allow plugins
> to use them

Not sure that's the way to go, if it was only the project plugin than
that might be a good idea, but more plugins might want to share
information in the future.

> - python allows runtime testing, maybe we should just take advantage of
> it and see how things go.

Letting python take care of things is fine by me, only downside is that
C plugins don't have access.

> Basically - if it wasn't clear - I am really scared by overengineering
> the solution. The new gedit plugin system is still young and I'd prefer
> see some more dust settle before expanding it.

Okay, I think we can do with only having python plugins access eachother
and no changes whatsoever to the plugin API.

> >>> - Decide what to do with the different ctags plugins. I personally don't
> >>> think ctags is really useful for the things we really want, decent code
> >>> completion
> >>>
> >>>   
> >>>       
> >> This is really a matter of someone interested in doing the work. I 
> >> personally don't use CTAGS, but many people do. If someone wants to pick 
> >> this up more power to him.
> >>     
> >
> > I don't either. But what ctags does is scan files and create an index of
> > all the tokens. The problem is, do we want a ctags parser (this would be
> > mostly just reading ctags and generate a list, which is what the plugin
> > I created a while ago does). Or do we want to have ctags functionality
> > (e.g. scan for tokens) which we can than use to do much more (again in
> > combination with the project plugin) like rescan on the fly, built
> > better and faster indexable cache of the available tokens. Ctags is nice
> > and all, but it requires the user to create the ctags file. When we know
> > all the files involved we can of course rescan those files with ctags
> > and than reparse the ctags file, but I'm generally against it :)
> >
> > I'd rather have a generic ctags like library which allows for easy
> > implementation, good indexing and easy updating. I've talked to anjuta
> > guys about this before, but they didn't seem interested. I think anjuta
> > took pieces of ctags and incorporated that in anjuta, but a separate
> > library would be nice. Maybe I'm just ambitious here.
> >
> >   
> Well, as I said this is just really up to who wants to have fun writing
> it. I really don't see one thing blocking the other: someone is used to
> ctags and wants to do a ctags plugin in gedit? Cool, I will not stop
> you! Someone else doesn't feel ctags is up to the job and wants to
> design a better solution? Even better, go for it! Want to turn it into a
> generic library that can be used by anjuta and others? Sure, sounds
> great! :)

Sure, I'm not saying that if people want a ctags plugin we should stop
them. I was more generally speaking about a code completion plugin and
spawning my own thoughts on the subject.


-- 
Jesse van den Kieboom

Visit: http://www.icecrew.nl