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

[Nick Treleaven]

On Mon, 18 Jan 2010 09:28:25 +1100
Lex Trotman <elextr at 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