On Mon, 18 Jan 2010 09:28:25 +1100 Lex Trotman <[email protected]> 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 _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
