-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Happy New Year to you guys ! Best wish to you and Geany :)
In reply to this discussion on the geany list: http://lists.uvena.de/pipermail/geany/2008-December/003878.html
I did my own version of the patch (in attachment). It still have following some flaws: - - when you insert an autoclosed char and immediatly delete it, the non-autoclose code kicks in anyway (I'm not sure how/where to deal with the delete keys) - - when inserting a quote (double or not), coming back before it and inserting another one, the non-autoclose code kicks in anyway. Should we test the next-char before non-autoclosing ? - - the test for matching bracket seems a bit too greedy as autoclose often doesn't kicks in because of a closing bracket few lines after.
Hadn't notice any lag with this code, however I wasn't notice lag with Enrico's patch neither...so someone with an older computer should probably check that.
Thanks for your next answer and review :) - -- Guillaume (ioguix) de Rorthais
On Wed, 07 Jan 2009 23:40:52 -0500, "JGuillaume (ioguix) de Rorthais" ioguix@free.fr wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Happy New Year to you guys ! Best wish to you and Geany :)
In reply to this discussion on the geany list: http://lists.uvena.de/pipermail/geany/2008-December/003878.html
I did my own version of the patch (in attachment). It still have following some flaws:
- when you insert an autoclosed char and immediatly delete it, the
non-autoclose code kicks in anyway (I'm not sure how/where to deal with the delete keys)
- when inserting a quote (double or not), coming back before it and
inserting another one, the non-autoclose code kicks in anyway. Should we test the next-char before non-autoclosing ?
- the test for matching bracket seems a bit too greedy as autoclose
often doesn't kicks in because of a closing bracket few lines after.
Additional problems: - the EditorInfo::autoclosed is not editor based so when inserting an autoclose char in an editor, then change to another one, the non-autoclose code kicks in when inserting the corresponding closing char, the solution would be to move the 'autoclosed' field into the GeanyEditor struct to make it editor-based but not sure whether it's worth it (this then gets added to the plugin API or we create a private part of GeanyEditor) - insert a '(', the ')' gets auto-inserted, move the cursor behind the auto-inserted ')' and insert another ')', the inserted closing brace is deleted by the non-autoclose code and the cursor is positioned off by one
This all seems kind of weird and hard to fix all cases. I'm afraid a sane implementation would cause a painful amount of extra code :(.
Regards, Enrico
Enrico Tröger schrieb:
This all seems kind of weird and hard to fix all cases. I'm afraid a sane implementation would cause a painful amount of extra code :(.
Regards, Enrico
This feature has been proven to be good in theory, but bad in practice anyway. At least for me. It's basically not usable on any language which needs some kind of statement terminator, such as C and its ;.
I see how it might be useful for other languages, but you still need to move the cursor behind the auto-inserted char to be able to hit enter to get to the next line. And I actually don't see a difference in typing " or moving the cursor.
Best regards, kugel
On Mon, 12 Jan 2009, Thomas Martitz wrote:
Enrico Tröger schrieb:
This all seems kind of weird and hard to fix all cases. I'm afraid a sane implementation would cause a painful amount of extra code :(.
Regards, Enrico
This feature has been proven to be good in theory, but bad in practice anyway. At least for me. It's basically not usable on any language which needs some kind of statement terminator, such as C and its ;.
I see how it might be useful for other languages, but you still need to move the cursor behind the auto-inserted char to be able to hit enter to get to the next line. And I actually don't see a difference in typing " or moving the cursor.
There's at least one: I have a reflex since some years now, that makes me closing immediatly anything I am opening, quotes, braces etc...It's not even like I was thinking about that, it really became a reflex now.
Considering that, this patch actually makes me save some keystroke on arrows. Consider this code print('blah'), I have to type 2 times on left, 2 times on right. With the patch, I just have to move forward 2 times when I finished typing "blah", never go back.
Considering some other editors got this kind of feature and that at least one user found this patch useful on the geany ml, I guess some other people have this same reflexe.
But I just defend the practice here to answer your first sentence, not the patch itself. I discovered this feature was more complexe I used to think and believe the first initial patch is incomplete. So if you guys decide to withdraw it from the source I will definitly not mind. As Enrico was pointing out, having a sane implementation of it would need some more amount of extra code. So maybe this is the signal to make us consider pushing this in a plugin if feasable. Though, I could try fixing the additionnal problems Enrico pointed out. Actually the only problem I see presently is the one with delete/backspace after autoclosing...
Best regards, kugel
Regards,
On Thu, 15 Jan 2009 05:41:18 +0100 (CET), ioguix@free.fr wrote:
On Mon, 12 Jan 2009, Thomas Martitz wrote:
Enrico Tröger schrieb:
This all seems kind of weird and hard to fix all cases. I'm afraid a sane implementation would cause a painful amount of extra code :(.
Regards, Enrico
This feature has been proven to be good in theory, but bad in practice anyway. At least for me. It's basically not usable on any language which needs some kind of statement terminator, such as C and its ;.
I see how it might be useful for other languages, but you still need to move the cursor behind the auto-inserted char to be able to hit enter to get to the next line. And I actually don't see a difference in typing " or moving the cursor.
There's at least one: I have a reflex since some years now, that makes me closing immediatly anything I am opening, quotes, braces etc...It's not even like I was thinking about that, it really became a reflex now.
Considering that, this patch actually makes me save some keystroke on arrows. Consider this code print('blah'), I have to type 2 times on left, 2 times on right. With the patch, I just have to move forward 2 times when I finished typing "blah", never go back.
Considering some other editors got this kind of feature and that at least one user found this patch useful on the geany ml, I guess some other people have this same reflexe.
But I just defend the practice here to answer your first sentence, not the patch itself. I discovered this feature was more complexe I used to think and believe the first initial patch is incomplete. So if you guys decide to withdraw it from the source I will definitly not mind. As Enrico was pointing out, having a sane implementation of it would need some more amount of extra code. So maybe this is the signal to make us consider pushing this in a plugin if feasable. Though, I could try fixing the additionnal problems Enrico pointed out. Actually the only problem I see presently is the one with delete/backspace after autoclosing...
Without answering the above issues, just a quick idea:
what do you think about further developing of this feature in a branch or a plugin? I currently don't have time and energy for the patch-review-commit cycle. So, in a branch you could constantly improve it further when you have time and motivation. Or, maybe better, in a plugin which probably would result in more user feedback as it is more likely to be used as in a separate branch. I could create a quick plugin skeleton if you are interested.
I think this way development could be faster and we can later merge it into Geany again or just keep it as a plugin.
Regards, Enrico
On Wed, 21 Jan 2009, Enrico Tröger wrote:
On Thu, 15 Jan 2009 05:41:18 +0100 (CET), ioguix@free.fr wrote:
On Mon, 12 Jan 2009, Thomas Martitz wrote:
Enrico Tröger schrieb:
This all seems kind of weird and hard to fix all cases. I'm afraid a sane implementation would cause a painful amount of extra code :(.
Regards, Enrico
This feature has been proven to be good in theory, but bad in practice anyway. At least for me. It's basically not usable on any language which needs some kind of statement terminator, such as C and its ;.
I see how it might be useful for other languages, but you still need to move the cursor behind the auto-inserted char to be able to hit enter to get to the next line. And I actually don't see a difference in typing " or moving the cursor.
There's at least one: I have a reflex since some years now, that makes me closing immediatly anything I am opening, quotes, braces etc...It's not even like I was thinking about that, it really became a reflex now.
Considering that, this patch actually makes me save some keystroke on arrows. Consider this code print('blah'), I have to type 2 times on left, 2 times on right. With the patch, I just have to move forward 2 times when I finished typing "blah", never go back.
Considering some other editors got this kind of feature and that at least one user found this patch useful on the geany ml, I guess some other people have this same reflexe.
But I just defend the practice here to answer your first sentence, not the patch itself. I discovered this feature was more complexe I used to think and believe the first initial patch is incomplete. So if you guys decide to withdraw it from the source I will definitly not mind. As Enrico was pointing out, having a sane implementation of it would need some more amount of extra code. So maybe this is the signal to make us consider pushing this in a plugin if feasable. Though, I could try fixing the additionnal problems Enrico pointed out. Actually the only problem I see presently is the one with delete/backspace after autoclosing...
Without answering the above issues, just a quick idea:
what do you think about further developing of this feature in a branch or a plugin? I currently don't have time and energy for the patch-review-commit cycle. So, in a branch you could constantly improve it further when you have time and motivation. Or, maybe better, in a plugin which probably would result in more user feedback as it is more likely to be used as in a separate branch. I could create a quick plugin skeleton if you are interested.
I think this way development could be faster and we can later merge it into Geany again or just keep it as a plugin.
Thanks for this proposal and sorry for my long non-answer...
Plugins sounds like a better way, as yuo say, a seperate branch would have very few users...
However, ISTM the biggest issue to this patch presently is to detect keystroke like delete/backspace and when moving the cursor in the document...Do you think I could get this kind of information from a plugin ?
Regards, Enrico
On Sun, 1 Feb 2009 05:14:42 +0100 (CET), ioguix@free.fr wrote:
what do you think about further developing of this feature in a branch or a plugin? I currently don't have time and energy for the patch-review-commit cycle. So, in a branch you could constantly improve it further when you have time and motivation. Or, maybe better, in a plugin which probably would result in more user feedback as it is more likely to be used as in a separate branch. I could create a quick plugin skeleton if you are interested.
I think this way development could be faster and we can later merge it into Geany again or just keep it as a plugin.
Thanks for this proposal and sorry for my long non-answer...
Plugins sounds like a better way, as yuo say, a seperate branch would have very few users...
However, ISTM the biggest issue to this patch presently is to detect keystroke like delete/backspace and when moving the cursor in the document...Do you think I could get this kind of information from a plugin ?
Yes, with the rather new "editor-notify" signal you have access to these information. See http://www.geany.org/manual/reference/signals.html, at the bottom "editor-notify" is described. A basic example implementation is shown in plugins/demoplugin.c.
If you want to create a plugin for this, think about adding it to the "geany-plugins" project, details at http://www.geany.org/manual/reference/guidelines.html.
Regards, Enrico