Hi all.
Everybody knows that Geany has menu item "Document > Strip trailing spaces" and option to do it automatically when a document is saved. My proposal is another command, something like "Strip trailing blank lines", to remove blank lines in the end of file (as they are absolutely useless there).
I wrote new `editor_strip_trailing_newlines' function (see the attached patch). Currently I call it directly from `document_save_file' if `strip_trailing_spaces' setting is set. Of course, it's not how it should be. Maybe separate menu item and option should be added, like for trailing spaces. Alternative way is to combine those, i.e., rename "Strip trailing spaces" to "Remove excessive whitespace" :-) These all are usability issues, with which I don't like to deal. If any of the developers has an opinion upon those, I'll consider it and update the patch.
P.S. My code leaves one trailing newline if `final_new_line' setting is set. Otherwise, it removes all trailing newlines. I believe it is right.
Everybody knows that Geany has menu item "Document > Strip trailing spaces" and option to do it automatically when a document is saved. My proposal is another command, something like "Strip trailing blank lines", to remove blank lines in the end of file (as they are absolutely useless there).
On this note and while people are working on stripping trailing space, would it be possible to have either a different strip command or some switch somewhere so that strip trailing whitespace results in this (using . for spaces/tabs):
for i in (@blah){ ...print "$i\n"; ... ...print "BLAH!\n"; }
Instead of this:
for i in (@blah){ ...print "$i\n";
...print "BLAH!\n"; }
Note that in the first the spaces/tabs are left to end at the current indent level, I suspect that there is a large amount of extra code to make this work as the strip will have to get clever and understand about a lot more things than it currently does.
ta
-- Andrew Janke (a.janke@gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883
On Wed, 26 Aug 2009 19:48:30 +0400, Eugene wrote:
Hey,
I wrote new `editor_strip_trailing_newlines' function (see the attached patch). Currently I call it directly from `document_save_file' if `strip_trailing_spaces' setting is set. Of course, it's not how it should be. Maybe separate menu item and option should be added, like for trailing spaces. Alternative way is to combine those, i.e., rename "Strip trailing spaces" to "Remove excessive whitespace" :-) These all are usability issues, with which I don't like to deal. If any of the developers has an opinion upon those, I'll consider it and update the patch.
Hmm, I'm not sure that would be an often used feature but of course it can be useful and you already wrote the code (and used it on the modified files in your patch...I like to have two or three trailing blank links at EOF :D). Back to the topic, what about putting this into a plugin?
Either as a separate plugin which might be a bit overhead, or as part of the addons plugin which aims to collect such small pieces of additions or as a new (core) plugin into which we could move the existing other both related features, too.
Just some thoughts. Opinions?
P.S. My code leaves one trailing newline if `final_new_line' setting is set. Otherwise, it removes all trailing newlines. I believe it is right.
Me too. Sounds reasonable.
Regards, Enrico
Hi Enrico.
Enrico Tro"ger wrote:
On Wed, 26 Aug 2009 19:48:30 +0400, Eugene wrote:
Hey,
I wrote new `editor_strip_trailing_newlines' function (see the attached patch). Currently I call it directly from `document_save_file' if `strip_trailing_spaces' setting is set. Of course, it's not how it should be. Maybe separate menu item and option should be added, like for trailing spaces. Alternative way is to combine those, i.e., rename "Strip trailing spaces" to "Remove excessive whitespace" :-) These all are usability issues, with which I don't like to deal. If any of the developers has an opinion upon those, I'll consider it and update the patch.
Hmm, I'm not sure that would be an often used feature but of course it can be useful and you already wrote the code (and used it on the modified files in your patch...I like to have two or three trailing blank links at EOF :D). Back to the topic, what about putting this into a plugin?
Either as a separate plugin which might be a bit overhead, or as part of the addons plugin which aims to collect such small pieces of additions or as a new (core) plugin into which we could move the existing other both related features, too.
Just some thoughts. Opinions?
Putting it to the addons plugin sounds reasonable. I'll do it this or next week.
Regards, Eugene.
On Thu, 27 Aug 2009 21:35:20 +0400, Eugene wrote:
Hi Enrico.
Enrico Tro"ger wrote:
On Wed, 26 Aug 2009 19:48:30 +0400, Eugene wrote:
Hey,
I wrote new `editor_strip_trailing_newlines' function (see the attached patch). Currently I call it directly from `document_save_file' if `strip_trailing_spaces' setting is set. Of course, it's not how it should be. Maybe separate menu item and option should be added, like for trailing spaces. Alternative way is to combine those, i.e., rename "Strip trailing spaces" to "Remove excessive whitespace" :-) These all are usability issues, with which I don't like to deal. If any of the developers has an opinion upon those, I'll consider it and update the patch.
Hmm, I'm not sure that would be an often used feature but of course it can be useful and you already wrote the code (and used it on the modified files in your patch...I like to have two or three trailing blank links at EOF :D). Back to the topic, what about putting this into a plugin?
Either as a separate plugin which might be a bit overhead, or as part of the addons plugin which aims to collect such small pieces of additions or as a new (core) plugin into which we could move the existing other both related features, too.
Just some thoughts. Opinions?
Putting it to the addons plugin sounds reasonable. I'll do it this or next week.
Cool. If you want SVN write access to commit your changes yourself, just tell me your Sourceforge username (and give me a a little time to set it up :D).
Regards, Enrico
Hi Enrico.
Enrico Tröger wrote:
If you want SVN write access to commit your changes yourself, just tell me your Sourceforge username (and give me a a little time to set it up :D).
I think there is no need for me to access SVN. I want to just send patches, if you don't mind :-)
The attached patches are new "blanklines" addons plugin. It required some API changes.
First, I had to add new "document-before-save" signal, so that my plugin can access a document _before_ it is saved (existing "document-save" signal is sent _after_ that). I described the new signal in "doc/plugins.dox" and in the code comments near document_save_file(). I hope, adding the signal does not break ABI compatibility (I did not check it).
Second, I exported some sciwrappers needed by the plugin. I think, maybe it worths converting one-line wrappers into macros, so that we won't need to export them.
Order of the patches is clear: geany.1.<...> is the first, geany.2.<...> is the second, geany.3.<...> is the third. Another patch is for geany-plugins. I tested updated geany and new plugin here, everything seems to work nicely.
Best regards, Eugene.
On Wed, 02 Sep 2009 20:11:21 +0400, Eugene wrote:
Hi Enrico.
Enrico Tröger wrote:
If you want SVN write access to commit your changes yourself, just tell me your Sourceforge username (and give me a a little time to set it up :D).
I think there is no need for me to access SVN. I want to just send patches, if you don't mind :-)
Fine with me. Whatever you want, SVN write access wouldn't be a problem but sending in patches is just as well.
The attached patches are new "blanklines" addons plugin. It required some API changes.
Great.
First, I had to add new "document-before-save" signal, so that my plugin can access a document _before_ it is saved (existing "document-save" signal is sent _after_ that). I described the new
Ok, I think that makes sense, there are probably more use-cases where this can be used.
signal in "doc/plugins.dox" and in the code comments near document_save_file(). I hope, adding the signal does not break ABI compatibility (I did not check it).
Yeah, it's fine.
Second, I exported some sciwrappers needed by the plugin. I think,
Ok. I think we could skip sci_get_line_end_position() but the others look fine.
maybe it worths converting one-line wrappers into macros, so that we won't need to export them.
But then we end up in some wrappers realised as macros, others as functions (those which have a little logic in it). You can also easily use Scintilla messages directly in your plugin code using the scintilla_send_message() function.
I'll commit your patches tomorrow or on Friday.
Regards, Enrico
Hi Enrico. Here are some comments about turning sciwrappers into macros.
Enrico Tro"ger wrote:
On Wed, 02 Sep 2009 20:11:21 +0400, Eugene wrote:
<...>
maybe it worths converting one-line wrappers into macros, so that we won't need to export them.
But then we end up in some wrappers realised as macros, others as functions (those which have a little logic in it).
Yes, but is it a problem?
You can also easily use Scintilla messages directly in your plugin code using the scintilla_send_message() function.
Yes, but if those macros were defined in geany, no plugin writers would need to write their own or using scintilla_send_message calls (which are little longer).
Anyway, using macros instead of functions is an insignificant suggestion, you can ignore that.
Best regards, Eugene.
On Thu, 03 Sep 2009 11:36:19 +0400, Eugene wrote:
Hi Enrico. Here are some comments about turning sciwrappers into macros.
Enrico Tro"ger wrote:
On Wed, 02 Sep 2009 20:11:21 +0400, Eugene wrote:
<...>
maybe it worths converting one-line wrappers into macros, so that we won't need to export them.
But then we end up in some wrappers realised as macros, others as functions (those which have a little logic in it).
Yes, but is it a problem?
Technically not at all. And yes, it would make it easier to add such wrappers to the plugin API, i.e. they would be part of it automatically in contrary to "real" functions which have to be exported explicitly. Still I think for documentation purpose it is easier if they are all in the same way implemented. Maybe it's just me. As you said, it's not that important and if others agree, we could make the very easy ones macros. But then, if we need to make them functions at some point to add a little logic inside or anything, it might get harder to keep it all compatible.
Regards, Enrico
On Wed, 2 Sep 2009 23:38:32 +0200, Enrico wrote:
On Wed, 02 Sep 2009 20:11:21 +0400, Eugene wrote:
Hi Enrico.
Enrico Tröger wrote:
If you want SVN write access to commit your changes yourself, just tell me your Sourceforge username (and give me a a little time to set it up :D).
I think there is no need for me to access SVN. I want to just send patches, if you don't mind :-)
Fine with me. Whatever you want, SVN write access wouldn't be a problem but sending in patches is just as well.
The attached patches are new "blanklines" addons plugin. It required some API changes.
Great.
First, I had to add new "document-before-save" signal, so that my plugin can access a document _before_ it is saved (existing "document-save" signal is sent _after_ that). I described the new
Ok, I think that makes sense, there are probably more use-cases where this can be used.
signal in "doc/plugins.dox" and in the code comments near document_save_file(). I hope, adding the signal does not break ABI compatibility (I did not check it).
Yeah, it's fine.
Second, I exported some sciwrappers needed by the plugin. I think,
Ok. I think we could skip sci_get_line_end_position() but the others look fine.
maybe it worths converting one-line wrappers into macros, so that we won't need to export them.
But then we end up in some wrappers realised as macros, others as functions (those which have a little logic in it). You can also easily use Scintilla messages directly in your plugin code using the scintilla_send_message() function.
I'll commit your patches tomorrow or on Friday.
Or on Sunday, sorry for the delay.
Regards, Enrico
On Sun, 6 Sep 2009 14:33:08 +0200, Enrico wrote:
I'll commit your patches tomorrow or on Friday.
Or on Sunday, sorry for the delay.
So, finally done. Thanks. I committed the Geany patches to add the requested extensions, also all of the sciwrappers.
Once we decided how to proceed with the next geany-plugins release, I'll put your changes to the addons plugin also in SVN (doing it now would break trunk and the coming 0.18 release of the plugins for Geany 0.18).
Regards, Enrico
On Sun, 6 Sep 2009 18:56:37 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 6 Sep 2009 14:33:08 +0200, Enrico wrote:
I'll commit your patches tomorrow or on Friday.
Or on Sunday, sorry for the delay.
So, finally done. Thanks. I committed the Geany patches to add the requested extensions, also all of the sciwrappers.
Once we decided how to proceed with the next geany-plugins release, I'll put your changes to the addons plugin also in SVN (doing it now would break trunk and the coming 0.18 release of the plugins for Geany 0.18).
Regards, Enrico
Thank you very much.