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.
Cheers, Frank
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?
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
Am Sonntag, den 17.01.2010, 16:48 +0100 schrieb Enrico Tröger:
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?
After all, I rather think we should keep it in the core even though it's mainly for the better user experience.
Exactly my point of view. I fully agree to Enrico here.
Regs, Dominic
Hi,
On Sun, 17 Jan 2010 16:48:43 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
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.
Of course, this would also apply to other code.
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.
Yes. auto_table() was just an example to start with.
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?
I could imagine of get rid off this by doing two things: - Giving the plugin a name. Something like SGMLauto - Establish a configurable connection between filetype and plugin similar ti what emacs is having for its modes. (I know, if this is a valid point, that this is nothing can be done within five minutes)
After all, I rather think we should keep it in the core even though it's mainly for the better user experience.
Yes, this is what I wasn't sure about so I've asked the list - the users ;).
Cheers, Frank
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
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