2010/1/18 Enrico Tröger enrico.troeger@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel