Hi all.
I have a suggestion and want to know if it makes sense for anyone else. Currently if you turn on "XML tag autocompletion" in Preferences > Editor > Completions, a table template is automatically inserted after you write "<table>". It seems that the template is in Geany's source code and can't be changed.
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise <table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
What do you think?
Best regards, Eugene.
On Tue, 19 Oct 2010 14:01:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
I have a suggestion and want to know if it makes sense for anyone else. Currently if you turn on "XML tag autocompletion" in Preferences > Editor > Completions, a table template is automatically inserted after you write "<table>". It seems that the template is in Geany's source code and can't be changed.
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise <table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
We could add a 'table' snippet. With the <> angle brackets you would probably get the automatic closing tag before pressing tab to complete the snippet.
Nick
On Tue, 19 Oct 2010 12:35:23 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 19 Oct 2010 14:01:09 +0400 Eugene Arshinov earshinov@gmail.com wrote:
I have a suggestion and want to know if it makes sense for anyone else. Currently if you turn on "XML tag autocompletion" in Preferences > Editor > Completions, a table template is automatically inserted after you write "<table>". It seems that the template is in Geany's source code and can't be changed.
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise <table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
We could add a 'table' snippet. With the <> angle brackets you would probably get the automatic closing tag before pressing tab to complete the snippet.
I think it's reasonable to remove "autotable" and add "table" snippet instead.
Best regards, Eugene.
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise <table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
We could add a 'table' snippet. With the <> angle brackets you would probably get the automatic closing tag before pressing tab to complete the snippet.
I think it's reasonable to remove "autotable" and add "table" snippet instead.
Perhaps this is better because then the user can decide when to use the completion, instead of always. Patch welcome.
Nick
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise
<table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Nice, I'll look at it sometime.
We could add a 'table' snippet. With the <> angle brackets you would probably get the automatic closing tag before pressing tab to complete the snippet.
I think it's reasonable to remove "autotable" and add "table" snippet instead.
Perhaps this is better because then the user can decide when to use the completion, instead of always. Patch welcome.
Attached :)
Best regards, Eugene.
On Sat, 23 Oct 2010 17:44:18 +0400 Eugene Arshinov earshinov@gmail.com wrote:
We could add a 'table' snippet. With the <> angle brackets you would probably get the automatic closing tag before pressing tab to complete the snippet.
I think it's reasonable to remove "autotable" and add "table" snippet instead.
Perhaps this is better because then the user can decide when to use the completion, instead of always. Patch welcome.
Attached :)
Committed, thanks.
Nick
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise
<table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Hi.
Extracting this into a plugin was a good idea. I decided to add a new one instead of extending HTML Chars because their functions are pretty different (though both related to XML and HTML). If I extended HTML Chars, I would need to add a checkbox to separately turn the completion-based-on-snippets on/off. In a separate plugin user achieve the same result by enabling/disabling the whole plugin, which is simpler and more obvious.
I called the new plugin "XML snippets". It's not pretty obvious, but I couldn't think of anything better and short enough. If you have an idea, feel free to rename it.
So, the patches to add the tiny plugin are attached: - the first adds/exports some necessary functions; - the second adds the plugin itself; - the third contains the changelog for the above two.
In the second patch I included some user documentation. Unfortunately, my rst2html is much more recent, so the most of geany.html got changed. Maybe it will be easier for you to ignore the changes in geany.html from the patch and regenerate it yourself from updated geany.txt. If my English is not good enough, please rewrite the documentation as you wish.
Also in the second patch there is a patch for ru.po to add Russian localisation for the plugin. I know there's a separate process for updating localisation, so it isn't my responsibility and you should probably ignore this change.
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
Best regards, Eugene.
Am 08.11.2010 10:55, schrieb Eugene Arshinov:
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
Didn't digg into the code too much but what about to put it to the plugins project?
Cheers, Frank
Le 08/11/2010 17:42, Frank Lanitz a écrit :
Am 08.11.2010 10:55, schrieb Eugene Arshinov:
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
Didn't digg into the code too much but what about to put it to the plugins project?
I think that since it is meant to hold a feature that would be removed from Geany's core (auto-table), it has it's place as Geany core plugins; so people that want it back don't necessarily need to get geany-plugins.
Regards, Colomban
On Mon, 08 Nov 2010 17:42:40 +0100% Frank Lanitz frank@frank.uvena.de wrote:
Am 08.11.2010 10:55, schrieb Eugene Arshinov:
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
Didn't digg into the code too much but what about to put it to the plugins project?
It's absolutely possible. I don't know precisely when you should put a plugin in geany and when in geany-plugins. I guess new plugins should go to geany-plugins, but this one is somewhat related to HTML Chars, which is in geany, and also it's very tiny (for reference I attach the full source code here). So I decided to put it into geany for the present.
Best regards, Eugene
On Mon, 08 Nov 2010 19:48:17 +0100% Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 08/11/2010 17:42, Frank Lanitz a écrit :
Am 08.11.2010 10:55, schrieb Eugene Arshinov:
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
Didn't digg into the code too much but what about to put it to the plugins project?
I think that since it is meant to hold a feature that would be removed from Geany's core (auto-table), it has it's place as Geany core plugins; so people that want it back don't necessarily need to get geany-plugins.
This is also a valid point. But, actually I doubt many users will miss table autocompletion :)
Best regards, Eugene.
Le 08/11/2010 10:55, Eugene Arshinov a écrit :
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise
<table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Hi.
Extracting this into a plugin was a good idea. I decided to add a new one instead of extending HTML Chars because their functions are pretty different (though both related to XML and HTML). If I extended HTML Chars, I would need to add a checkbox to separately turn the completion-based-on-snippets on/off. In a separate plugin user achieve the same result by enabling/disabling the whole plugin, which is simpler and more obvious.
Am I right that the simple automatic tag closing is not part of the plugin but still in Geany itself? If so, I think it's confusing, because these are really close concepts, and it can be viewed as some "default snippets".
This said, I like the idea of moving this to a plugin; having this kind of specific stuff on the core is convenient but not that clean IMO :)
I called the new plugin "XML snippets". It's not pretty obvious, but I couldn't think of anything better and short enough. If you have an idea, feel free to rename it.
So, the patches to add the tiny plugin are attached:
- the first adds/exports some necessary functions;
editor_get_snippets_for_file_type() seems to lack a return statement.
- the second adds the plugin itself;
I think that plugins/geanyfunctions.h changes should be in 1, not 2. Right? Also, I can't see the update of the po/POTFILES.in, is it missing?
I would personally mark the "gchar *completion" variable in the plugin's editor_notify_cb() as const since it must not me modified/freed/etc., but it's a perhaps personal taste.
- the third contains the changelog for the above two.
In the second patch I included some user documentation. Unfortunately, my rst2html is much more recent, so the most of geany.html got changed. Maybe it will be easier for you to ignore the changes in geany.html from the patch and regenerate it yourself from updated geany.txt. If my English is not good enough, please rewrite the documentation as you wish.
Also in the second patch there is a patch for ru.po to add Russian localisation for the plugin. I know there's a separate process for updating localisation, so it isn't my responsibility and you should probably ignore this change.
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
See above :)
Regards, Colomban
On Mon, 08 Nov 2010 20:12:21 +0100% Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 08/11/2010 10:55, Eugene Arshinov a écrit :
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise
<table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Hi.
Extracting this into a plugin was a good idea. I decided to add a new one instead of extending HTML Chars because their functions are pretty different (though both related to XML and HTML). If I extended HTML Chars, I would need to add a checkbox to separately turn the completion-based-on-snippets on/off. In a separate plugin user achieve the same result by enabling/disabling the whole plugin, which is simpler and more obvious.
Am I right that the simple automatic tag closing is not part of the plugin but still in Geany itself?
Yes
If so, I think it's confusing, because these are really close concepts, and it can be viewed as some "default snippets".
This said, I like the idea of moving this to a plugin; having this kind of specific stuff on the core is convenient but not that clean IMO :)
Yes, maybe it is confusing. But, at least, it works :)
I called the new plugin "XML snippets". It's not pretty obvious, but I couldn't think of anything better and short enough. If you have an idea, feel free to rename it.
So, the patches to add the tiny plugin are attached:
- the first adds/exports some necessary functions;
editor_get_snippets_for_file_type() seems to lack a return statement.
Seems that I forgot to use my custom CFLAGS with warnings… Anyway, it is strange because I tested the plugin and it worked. Maybe I accidently removed the return statement later…
- the second adds the plugin itself;
I think that plugins/geanyfunctions.h changes should be in 1, not 2. Right? Also, I can't see the update of the po/POTFILES.in, is it missing?
Both true.
I would personally mark the "gchar *completion" variable in the plugin's editor_notify_cb() as const since it must not me modified/freed/etc., but it's a perhaps personal taste.
Agree. Recently one "const gchar*" helped me to fix a possible bug with freeing.
- the third contains the changelog for the above two.
In the second patch I included some user documentation. Unfortunately, my rst2html is much more recent, so the most of geany.html got changed. Maybe it will be easier for you to ignore the changes in geany.html from the patch and regenerate it yourself from updated geany.txt. If my English is not good enough, please rewrite the documentation as you wish.
Also in the second patch there is a patch for ru.po to add Russian localisation for the plugin. I know there's a separate process for updating localisation, so it isn't my responsibility and you should probably ignore this change.
If you have any objections about the code or the functionality of the plugin, please write. I will update the code as needed.
See above :)
Thank you very much for reviewing. Updated patches are attached.
Regards, Colomban _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
New xmlsnippet.c got lost from the second patch. Please use this one.
On Mon, 8 Nov 2010 12:55:23 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise
<table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Hi.
Extracting this into a plugin was a good idea. I decided to add a new one instead of extending HTML Chars because their functions are pretty different (though both related to XML and HTML). If I extended HTML Chars, I would need to add a checkbox to separately turn the completion-based-on-snippets on/off. In a separate plugin user achieve the same result by enabling/disabling the whole plugin, which is simpler and more obvious.
I called the new plugin "XML snippets". It's not pretty obvious, but I couldn't think of anything better and short enough. If you have an idea, feel free to rename it.
I'm not sure that it should be distributed with Geany, I think the 'table' snippet is enough to replace auto-table. The plugin could be added to geany-plugins though.
About the API changes:
- &editor_get_snippets_for_file_type,
- &editor_insert_snippet
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
(I haven't really looked at editor_insert_snippet yet.)
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
- &sci_is_string_style,
- &sci_is_comment_style,
- &sci_is_code_style
I think these would fit better in highlighting.c, but could then be part of the API. They're not really related to Scintilla messages, and it would group lexer information in the same file.
- &utils_find_open_xml_tag
Ok.
Nick
On Thu, 11 Nov 2010 17:42:49 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 8 Nov 2010 12:55:23 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Fri, 22 Oct 2010 13:38:42 +0100% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 12:51:10 +0400 Eugene Arshinov earshinov@gmail.com wrote:
The suggestion is to make use of snippets: if "table" or "<table>" snippet is specified in [HTML] section of snippets.conf, the snippet is automatically inserted, otherwise <table> tag is just closed, like other tags now. This should also work for any other tag.
Though, you can just define a snippet (say, "table") and use it when you want to insert a table. I doubt it's worth implementing the suggestion if everything it gives is the ability to type "<table>" instead of typing "table" and pressing complete-snippet keybinding.
Perhaps the behaviour could be moved to the 'HTML chars' plugin, which could be renamed HTML or Markup.
Geany will have to notify the plugin about every char added. Won't it be too "heavy" to send a signal in this case?
Actually, this is already done for that plugin. See the editor-notify signal.
Hi.
Extracting this into a plugin was a good idea. I decided to add a new one instead of extending HTML Chars because their functions are pretty different (though both related to XML and HTML). If I extended HTML Chars, I would need to add a checkbox to separately turn the completion-based-on-snippets on/off. In a separate plugin user achieve the same result by enabling/disabling the whole plugin, which is simpler and more obvious.
I called the new plugin "XML snippets". It's not pretty obvious, but I couldn't think of anything better and short enough. If you have an idea, feel free to rename it.
I'm not sure that it should be distributed with Geany, I think the 'table' snippet is enough to replace auto-table. The plugin could be added to geany-plugins though.
OK, I'll port it.
About the API changes:
- &editor_get_snippets_for_file_type,
- &editor_insert_snippet
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
The reason why I decided to export a hash table is that it allows a plugin to decide independently whether to account "default" snippets or just use the ones specified directly for the filetype (I must note that there is currently no separate function to get the default snippets, and relying on the fact that one can get it by passing "default" as filetype name is really bad). If we provide a function like editor_find_snippet, we need to fix the behaviour in it or add a boolean argument. Now I think, the latter is the best choice. Your opinion?
(I haven't really looked at editor_insert_snippet yet.)
Basically there was some code common for snippet insertion and (recently introduced) snippet keybindings. As I needed similar functionality in the plugin, I extracted it to a separate function and exported.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
- &sci_is_string_style,
- &sci_is_comment_style,
- &sci_is_code_style
I think these would fit better in highlighting.c, but could then be part of the API. They're not really related to Scintilla messages, and it would group lexer information in the same file.
OK, I will move them.
- &utils_find_open_xml_tag
Ok.
Nick _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 11 Nov 2010 21:09:32 +0300 Eugene Arshinov earshinov@gmail.com wrote:
About the API changes:
- &editor_get_snippets_for_file_type,
- &editor_insert_snippet
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
The reason why I decided to export a hash table is that it allows a plugin to decide independently whether to account "default" snippets or just use the ones specified directly for the filetype (I must note that there is currently no separate function to get the default snippets, and relying on the fact that one can get it by passing "default" as filetype name is really bad). If we provide a function like editor_find_snippet, we need to fix the behaviour in it or add a boolean argument. Now I think, the latter is the best choice. Your opinion?
Do plugins need to look up a default snippet?
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
(I haven't really looked at editor_insert_snippet yet.)
Basically there was some code common for snippet insertion and (recently introduced) snippet keybindings. As I needed similar functionality in the plugin, I extracted it to a separate function and exported.
Ok.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Nick
On Thu, 11 Nov 2010 18:33:14 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 11 Nov 2010 21:09:32 +0300 Eugene Arshinov earshinov@gmail.com wrote:
About the API changes:
- &editor_get_snippets_for_file_type,
- &editor_insert_snippet
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
The reason why I decided to export a hash table is that it allows a plugin to decide independently whether to account "default" snippets or just use the ones specified directly for the filetype (I must note that there is currently no separate function to get the default snippets, and relying on the fact that one can get it by passing "default" as filetype name is really bad). If we provide a function like editor_find_snippet, we need to fix the behaviour in it or add a boolean argument. Now I think, the latter is the best choice. Your opinion?
Do plugins need to look up a default snippet?
Currently no. And when such a plugin appears, we can always extend the API. It seems to be another reason to keep it simple and use editor_find_snippet(doc, snippet_name).
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
(I haven't really looked at editor_insert_snippet yet.)
Basically there was some code common for snippet insertion and (recently introduced) snippet keybindings. As I needed similar functionality in the plugin, I extracted it to a separate function and exported.
Ok.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Best regards, Eugene.
On Thu, 11 Nov 2010 21:46:51 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
The reason why I decided to export a hash table is that it allows a plugin to decide independently whether to account "default" snippets or just use the ones specified directly for the filetype (I must note that there is currently no separate function to get the default snippets, and relying on the fact that one can get it by passing "default" as filetype name is really bad). If we provide a function like editor_find_snippet, we need to fix the behaviour in it or add a boolean argument. Now I think, the latter is the best choice. Your opinion?
Do plugins need to look up a default snippet?
Currently no. And when such a plugin appears, we can always extend the API. It seems to be another reason to keep it simple and use editor_find_snippet(doc, snippet_name).
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
Great, then we can still change snippet implementation if we decide to without breaking the API.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Name clashes could be important though, in case the snippets are meant for JavaScript. One idea could be to check if the first char of the snippet body is '<'.
To do that, editor_find_snippet should return the snippet body.
Nick
On Mon, 8 Nov 2010 21:55:59 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I don't know precisely when you should put a plugin in geany and when in geany-plugins.
Just to explain a bit: usually new plugins should go in geany-plugins. That way you can maintain it independently from Geany, which is probably better for both of us ;-)
Nick
On Fri, 12 Nov 2010 12:51:48 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 11 Nov 2010 21:46:51 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I'm not sure these are necessary, particularly editor_get_snippets_for_file_type - I don't want to expose the snippet data structures unnecessarily. Perhaps editor_find_snippet(doc, snippet_name) instead?
The reason why I decided to export a hash table is that it allows a plugin to decide independently whether to account "default" snippets or just use the ones specified directly for the filetype (I must note that there is currently no separate function to get the default snippets, and relying on the fact that one can get it by passing "default" as filetype name is really bad). If we provide a function like editor_find_snippet, we need to fix the behaviour in it or add a boolean argument. Now I think, the latter is the best choice. Your opinion?
Do plugins need to look up a default snippet?
Currently no. And when such a plugin appears, we can always extend the API. It seems to be another reason to keep it simple and use editor_find_snippet(doc, snippet_name).
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
Great, then we can still change snippet implementation if we decide to without breaking the API.
I attach the updated patch. It contains all the changes in Geany necessary for the plugin, and a corresponding Changelog entry. Seems that I fixed all the issues we discussed.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Name clashes could be important though, in case the snippets are meant for JavaScript. One idea could be to check if the first char of the snippet body is '<'.
To do that, editor_find_snippet should return the snippet body.
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful). Obviously I will never type <lia> intentionally, but still it isn't nice. As we decided that it's necessary for the plugin to catch up Geany's snippets, we have only two options: to ignore this issue or to think of a better check. Currently I have no ideas, can you suggest some?
Best regards, Eugene.
On Sat, 13 Nov 2010 12:44:03 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
Great, then we can still change snippet implementation if we decide to without breaking the API.
I attach the updated patch. It contains all the changes in Geany necessary for the plugin, and a corresponding Changelog entry. Seems that I fixed all the issues we discussed.
Applied, thanks.
BTW your implementation of editor_insert_snippet was probably buggy. I restored the use of read_indent and -1 for newline_indent_size. Otherwise multiple cursor positions with tabs+spaces mode probably wouldn't work.
I'm not sure about having snippet names enclosed in <> angle brackets in snippets.conf, maybe.
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Name clashes could be important though, in case the snippets are meant for JavaScript. One idea could be to check if the first char of the snippet body is '<'.
To do that, editor_find_snippet should return the snippet body.
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful).
Why would <lia> be kept? That should be removed, otherwise <table> would result in <table><table>...</table>
If that is done, <lia> would be useful.
Obviously I will never type <lia> intentionally, but still it isn't nice. As we decided that it's necessary for the plugin to catch up Geany's snippets, we have only two options: to ignore this issue or to think of a better check. Currently I have no ideas, can you suggest some?
I don't think it's a problem.
Nick
On Tue, 16 Nov 2010 15:12:32 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 13 Nov 2010 12:44:03 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
Great, then we can still change snippet implementation if we decide to without breaking the API.
I attach the updated patch. It contains all the changes in Geany necessary for the plugin, and a corresponding Changelog entry. Seems that I fixed all the issues we discussed.
Applied, thanks.
BTW your implementation of editor_insert_snippet was probably buggy. I restored the use of read_indent and -1 for newline_indent_size. Otherwise multiple cursor positions with tabs+spaces mode probably wouldn't work.
Ah, OK. Seems that I investigated that argument not thorough enough.
> I'm not sure about having snippet names enclosed in <> > angle brackets in snippets.conf, maybe. >
I explained it a bit in the documentation (geany.txt): "It allows you to define snippets, which need not to be automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Name clashes could be important though, in case the snippets are meant for JavaScript. One idea could be to check if the first char of the snippet body is '<'.
To do that, editor_find_snippet should return the snippet body.
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful).
Why would <lia> be kept? That should be removed, otherwise <table> would result in <table><table>...</table>
If that is done, <lia> would be useful.
Obviously I will never type <lia> intentionally, but still it isn't nice. As we decided that it's necessary for the plugin to catch up Geany's snippets, we have only two options: to ignore this issue or to think of a better check. Currently I have no ideas, can you suggest some?
I don't think it's a problem.
Yes, removing the tag is a good idea, especially if we account that it's how "ordinary" snippets work now. I had an idea that for snippets for the plugin snippet body should contain only the part that's inserted (i.e., shouldn't contain the first open tag) because it easily allows to save attributes user may have specified in the open tag that gets autocompleted. If we remove this tag, we'll have to copy the attributes to the first tag within snippet body, but I think it's easy to implement.
Best regards, Eugene.
On Tue, 16 Nov 2010 19:01:41 +0300% Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 16 Nov 2010 15:12:32 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 13 Nov 2010 12:44:03 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Anyway perhaps editor_find_snippet(snippet_name, ft) is more flexible. Perhaps passing NULL for ft could lookup a default snippet, if that's necessary.
Yes, I think it's a good alternative to additional function argument.
Great, then we can still change snippet implementation if we decide to without breaking the API.
I attach the updated patch. It contains all the changes in Geany necessary for the plugin, and a corresponding Changelog entry. Seems that I fixed all the issues we discussed.
Applied, thanks.
BTW your implementation of editor_insert_snippet was probably buggy. I restored the use of read_indent and -1 for newline_indent_size. Otherwise multiple cursor positions with tabs+spaces mode probably wouldn't work.
Ah, OK. Seems that I investigated that argument not thorough enough.
> > I'm not sure about having snippet names enclosed in <> > > angle brackets in snippets.conf, maybe. > > > > I explained it a bit in the documentation (geany.txt): "It > allows you to define snippets, which need not to be > automatically inserted, without any name clashes".
Ok, but I'm not keen on distributing <tag> snippets with Geany, it just seems ugly having some 'tag' snippets, some '<tag>'. I see the reason though.
Ah, again I missed something. If in the plugin I use 'tag', the plugin will automatically support 'table' snippet included in Geany since recently. I think it's more important than preventing name clashes, so it's probable worth changing to 'tag'.
Name clashes could be important though, in case the snippets are meant for JavaScript. One idea could be to check if the first char of the snippet body is '<'.
To do that, editor_find_snippet should return the snippet body.
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful).
Why would <lia> be kept? That should be removed, otherwise <table> would result in <table><table>...</table>
If that is done, <lia> would be useful.
Obviously I will never type <lia> intentionally, but still it isn't nice. As we decided that it's necessary for the plugin to catch up Geany's snippets, we have only two options: to ignore this issue or to think of a better check. Currently I have no ideas, can you suggest some?
I don't think it's a problem.
Yes, removing the tag is a good idea, especially if we account that it's how "ordinary" snippets work now. I had an idea that for snippets for the plugin snippet body should contain only the part that's inserted (i.e., shouldn't contain the first open tag) because it easily allows to save attributes user may have specified in the open tag that gets autocompleted. If we remove this tag, we'll have to copy the attributes to the first tag within snippet body, but I think it's easy to implement.
…easy to implement if we don't consider the case when the first tag already contains attributes, especially when names of those attributes match the ones of the attributes user entered in the autocompleted tag…
Best regards, Eugene.
Am 12.11.2010 14:07, schrieb Nick Treleaven:
On Mon, 8 Nov 2010 21:55:59 +0300 Eugene Arshinov earshinov@gmail.com wrote:
I don't know precisely when you should put a plugin in geany and when in geany-plugins.
Just to explain a bit: usually new plugins should go in geany-plugins. That way you can maintain it independently from Geany, which is probably better for both of us ;-)
As well as its not bloating the Geany main distribution. ;)
Cheers, Frank
On Tue, 16 Nov 2010 19:06:59 +0300 Eugene Arshinov earshinov@gmail.com wrote:
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful).
Why would <lia> be kept? That should be removed, otherwise <table> would result in <table><table>...</table>
Yes, removing the tag is a good idea, especially if we account that it's how "ordinary" snippets work now. I had an idea that for snippets for the plugin snippet body should contain only the part that's inserted (i.e., shouldn't contain the first open tag) because it easily allows to save attributes user may have specified in the open tag that gets autocompleted. If we remove this tag, we'll have to copy the attributes to the first tag within snippet body, but I think it's easy to implement.
I would implement it to not autocomplete tags with attributes, only match '<' + snippet_name + '>'. The user could add any attributes after snippet insertion.
…easy to implement if we don't consider the case when the first tag already contains attributes, especially when names of those attributes match the ones of the attributes user entered in the autocompleted tag…
Nick
On Wed, 17 Nov 2010 14:48:49 +0000% Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 16 Nov 2010 19:06:59 +0300 Eugene Arshinov earshinov@gmail.com wrote:
In [HTML] section I have a snippet
lia=<li><a href="%cursor%">%cursor%</a></li>
It begins with a tag, so the plugin will insert it after I type <lia> (it will result in <lia><li><a ...>...</a></li> which isn't useful).
Why would <lia> be kept? That should be removed, otherwise
<table> would result in <table><table>...</table>
Yes, removing the tag is a good idea, especially if we account that it's how "ordinary" snippets work now. I had an idea that for snippets for the plugin snippet body should contain only the part that's inserted (i.e., shouldn't contain the first open tag) because it easily allows to save attributes user may have specified in the open tag that gets autocompleted. If we remove this tag, we'll have to copy the attributes to the first tag within snippet body, but I think it's easy to implement.
I would implement it to not autocomplete tags with attributes, only match '<' + snippet_name + '>'. The user could add any attributes after snippet insertion.
Yes, but moving cursor back and forth for that, I think, would be too annoying. User can insert %cursor% when he might want to insert attributes, but I think it isn't convenient too. Moreover, this will be a regression against the HTML table template which was built-in previously (of course, a minor regression, but still).
For me as a user an acceptable solution would be copy "input attributes" to the first tag of snippet body (we already search for the first tag, by the way), if the latter does not already contain attributes (which will be true most of the time). And implementing copying appeared not so hard for me, so I implemented it. The code got larger than I expected, but I still thing it is normal for the benefit it gives.
I need to copy attributes before editor.c:snippets_make_replacements runs to get correct cursor positions, so I have to escape the attributes string. But, in order the string got "unescaped" properly, I had to fix the bug with {ob} and {cb} templates. This is the first patch.
The previous version of the patch incorrectly left the typed tag intact. To remove it I had to get open_xml_tag_pos instead of open_xml_tag. I added the corresponding function and exported it. This is the second patch.
If you have some free time, please review and commit. (I start to think geany-devel would be the proper place for this discussion :-))
BTW, here is the current code of the plugin: http://nopaste.geany.org/p/m5d408564. It looks a bit scary because of not-so-useful structs, but it's the way I chose to group pointers by what they point to (input or snippet), otherwise I got confused quickly. My little C experience suggests me nothing less ugly.
Best regards, Eugene.