[Geany-devel] Moving XML/HTML specific stuff into plugin

[Lex Trotman]

2010/1/18 Enrico Tröger <enrico.troeger at uvena.de>:
> On Sat, 16 Jan 2010 20:52:04 +0100, Frank wrote:
>
>>Hi
>>
>>During my work on moving some LaTeX specific functions from Geany core
>>to geanyLaTeX plugin I recognized some code which is pretty much
>>HTML/XML specific and might would make sense to move also into a
>>plugin. On first step I was thinking about moving auto_table() out of
>>editor.c, but there are a couple of more things like the automatic
>>closing of XML tags which might would make sense to move into a
>>separate plugin.
>>
>>Lets give you a short list of advantages/disadvantages I can imagine
>>off doing such a step:
>>
>>Advantages:
>>+ Geany's core is keeping small and as we don't need to care about too
>>much filetype specific stuff
>>+ Save some CPU cycles on every change on editor widget for users which
>>don't use XML/HTML as the check for this types will not be needed
>>anymore
>>+ More flexibility in upgrading the fileype specific functions when
>>realized as a plugin
>>* Possible more configuration possibilities for user without bloating
>>Geany's preferences dialogues itself for non-XML/HTML users
>>
>>Disadvantages
>>- With a new plugin the user needs to know about and needs to activate
>>it
>>- User might think Geany is not support HTML properly as he wasn't
>>aware of n-1
>>- Additional overhead on
>>       * coding
>>       * running the plugin through plugin API
>>
>>Please let me know what you think about.
>
> I'm not sure whether we should do this.
> Basically you are completely right about moving filetype specific code
> from the core into a plugin. But we also have little specifics for
> other filetypes, e.g. auto indenting in Python after typing a colon.
> These little things don't match the requirement to be moved into a
> plugin, IMO. Though in case of the HTML/XML features, there is a lot
> more stuff which we do so we are talking about a good bunch of code not
> only a few lines.
> Still I think it could become a bit cumbersome for users to enable a
> specific plugin to have the functionality they were used to have in
> Geany for ages.
> And then there is the fact the code in question in used for HTML *and*
> XML which are two separate filetypes. How should a user expect that he
> have to enable a HTML plugin to get tag auto closing in XML files?
>

Although Geany is not excessively large yet (one of my previous
discussions with Nick) I think that the principle of having language
specifics external to the core is the way to go in the long run.

Can the filetype file specify a plugin to be automatically loaded when
the language is first used, this will remove the need for the user to
have to load it.  And give a friendly message if the plugin isn't
available, saying that it would make extra functionality available for
language xxx if plugin xxx_lang is available.  This would also allow
new languages to be added ex-core.

And for all the very small language specific parts, can they be all in
one omnibus plugin like your add-ons plugin?

Of course none of this has to change overnight, it can happen progressively.

Cheers
Lex

> After all, I rather think we should keep it in the core even though
> it's mainly for the better user experience.
>
> Just my 2.5 cents.
>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>