On Mon, 18 Jan 2010 09:28:25 +1100 Lex Trotman elextr@gmail.com wrote:
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.
BTW I think probably efficiency isn't an issue here, except: * making the core smaller makes it more efficient for anyone not using the SGML stuff. * Running code from a shared library is less efficient than binary, but perhaps this doesn't matter much for simple things like line parsing (Neil from scintilla said lexing would be slower from a shared library).
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.
I think we should support flexible auto-indenting for filetypes, so: * Indent on pressing enter after a line matching an autoindent_regex * Unindent on matching an autounindent_regex.
Just mentioning this as general features are better than hardcoded features.
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.
I agree. In this case I'm not sure if it's worth it ATM as: * SGML is very common, it's likely the user does use it sometimes * It breaks compatibility with existing core settings
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.
...
Maybe we could do something like this, not sure.
Regards, Nick