Hi guys,
I took a look at #3041948 [1] and did a prototype patch (attached) to fix it. Basically it's about the behavior of the Home and End keys regarding wrapped lines. We have configurable keybindings already, but they don't really make the editor display-line-friendly since they don't change the behavior of <Shift>Home and <Shift>End, aka selection extension.
Instead of repeating me, I'll quote the attached patch:
Add setting to make Home and End keys navigate in display coordinates
This cannot really be mapped using the keybinding because holding Shift together with Home or End is expected to behave exactly the same as without it but extending the selection; which is tricky to get using configurable bindings.
For this setting to behave correctly, the Home and End keys should obviously not be bound to any action, so the default bidings of Home and End should most probably be removed. Maybe the "Go to [display] line start/end" actions should be removed altogether now a global setting can be used to choose one behavior or the other; but they can also be kept but unmapped by default, which would allow a user to map another key to this action (like <Ctrl>A and <Ctrl>E to emulate a Bash/Emacs-like behavior).
Closes #3041948.
So, what do you think? Is this a correct way to fix this, or should we rather either add (4) separate configurable bindings for extending the selection to the start/end? Or should we add a trick to extend selection when <Shift> is pressed together with one of the current bindings (that's probably not a good idea in the (unlikely) case one binds one of these actions to <Shift>Something)?
Also, should we remove the bidings if we add that? Or should be just not bind them by default?
What about backward compatibility?
Looking forward to read you :) Regards, Colomban
[1] https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3041948...
PS: This uses 2 new Scintilla (not yet released) commands to respect "smart home key" feature when dealing with display lines, so you'll need a patch for that too -- attached. PPS: 3rd patch is to make "move to start of display line" command respect the "smart home" feature, too.
On 29 August 2012 04:02, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
I took a look at #3041948 [1] and did a prototype patch (attached) to fix it. Basically it's about the behavior of the Home and End keys regarding wrapped lines. We have configurable keybindings already, but they don't really make the editor display-line-friendly since they don't change the behavior of <Shift>Home and <Shift>End, aka selection extension.
Instead of repeating me, I'll quote the attached patch:
Add setting to make Home and End keys navigate in display coordinates
This cannot really be mapped using the keybinding because holding Shift together with Home or End is expected to behave exactly the same as without it but extending the selection; which is tricky to get using configurable bindings.
For this setting to behave correctly, the Home and End keys should obviously not be bound to any action, so the default bidings of Home and End should most probably be removed. Maybe the "Go to [display] line start/end" actions should be removed altogether now a global setting can be used to choose one behavior or the other; but they can also be kept but unmapped by default, which would allow a user to map another key to this action (like <Ctrl>A and <Ctrl>E to emulate a Bash/Emacs-like behavior).
Closes #3041948.
So, what do you think? Is this a correct way to fix this, or should we rather either add (4) separate configurable bindings for extending the selection to the start/end? Or should we add a trick to extend selection when <Shift> is pressed together with one of the current bindings (that's probably not a good idea in the (unlikely) case one binds one of these actions to <Shift>Something)?
Also, should we remove the bidings if we add that? Or should be just not bind them by default?
What about backward compatibility?
Hi Colomban,
Backward compatibility is absolutely essential, Geany must ship working as it does now !!!!!!!
I don't see the point of going to the end of the "visual" line since that is just some arbitrary point at which the line is wrapped, it is unlikely to be significant, except you might want to add a line break there. Going to the actual start and end of the line is much more common IMNSHO, so it should be the default (as it is now).
If a user prefers to navigate by visual line, fine, they can change the bindings as you said.
The best way of handling "extend selection to end of visible/real line" would be to also make those keybindings that the user can set, with defaults as now and <shift><alt>home/end for the extend visual. So again Geany works as now by default, the opposite behaviour is available, and users who prefer it can change the bindings to make it their default.
Cheers Lex
Looking forward to read you :) Regards, Colomban
[1] https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3041948...
PS: This uses 2 new Scintilla (not yet released) commands to respect "smart home key" feature when dealing with display lines, so you'll need a patch for that too -- attached. PPS: 3rd patch is to make "move to start of display line" command respect the "smart home" feature, too.
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 29/08/2012 02:34, Lex Trotman a écrit :
On 29 August 2012 04:02, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
I took a look at #3041948 [1] and did a prototype patch (attached) to fix it. Basically it's about the behavior of the Home and End keys regarding wrapped lines. We have configurable keybindings already, but they don't really make the editor display-line-friendly since they don't change the behavior of <Shift>Home and <Shift>End, aka selection extension.
Instead of repeating me, I'll quote the attached patch:
Add setting to make Home and End keys navigate in display coordinates
This cannot really be mapped using the keybinding because holding Shift together with Home or End is expected to behave exactly the same as without it but extending the selection; which is tricky to get using configurable bindings.
For this setting to behave correctly, the Home and End keys should obviously not be bound to any action, so the default bidings of Home and End should most probably be removed. Maybe the "Go to [display] line start/end" actions should be removed altogether now a global setting can be used to choose one behavior or the other; but they can also be kept but unmapped by default, which would allow a user to map another key to this action (like <Ctrl>A and <Ctrl>E to emulate a Bash/Emacs-like behavior).
Closes #3041948.
So, what do you think? Is this a correct way to fix this, or should we rather either add (4) separate configurable bindings for extending the selection to the start/end? Or should we add a trick to extend selection when <Shift> is pressed together with one of the current bindings (that's probably not a good idea in the (unlikely) case one binds one of these actions to <Shift>Something)?
Also, should we remove the bidings if we add that? Or should be just not bind them by default?
What about backward compatibility?
Hi Colomban,
Hey Lex,
Backward compatibility is absolutely essential, Geany must ship working as it does now !!!!!!!
I inserted other words than "backward" and "compatibility" in my mail, you know? :D
I don't see the point of going to the end of the "visual" line since that is just some arbitrary point at which the line is wrapped, it is unlikely to be significant, except you might want to add a line break there. Going to the actual start and end of the line is much more common IMNSHO, so it should be the default (as it is now).
This depends a lot on what's the displayed text I think. When writing programming languages yes, going to the visual EOL doesn't seem so useful; but if writing a long paragraph, you may want to move rapidly to a position that happens to be near visual EOL, so you might want to hit End.
Moreover, since visual lines may only be different from logical lines when line wrapping is enabled, one might argue that most people don't care for programming languages since most people don't activate line wrapping on them.
If a user prefers to navigate by visual line, fine, they can change the bindings as you said.
The best way of handling "extend selection to end of visible/real line" would be to also make those keybindings that the user can set, with defaults as now and <shift><alt>home/end for the extend visual. So again Geany works as now by default, the opposite behaviour is available, and users who prefer it can change the bindings to make it their default.
This is doable, but:
1) it adds 4 new "useless" keybindings 2) somebody who wants to change to "display line mode" needs to change 8 bindings (well, 4 manually at least).
I totally agree however it's a perfectly OK solution, and that it has the main advantage of not raising any other questions.
However, first note that the patch I proposed do NOT change anything by default and WON'T break any compatibility. No evil here.
The thing is that we bind Home and End by default [1], so those bindings would override the Scintilla defaults my patch sets; and thus would "break" the setting. And here comes the compatibility question if we'd like to avoid the issue. But see that even removing the bindings altogether would only affect people who actually changed it, e.g. 0.01% of the users maybe (no, I'm NOT saying we can shit on 'em) so even a break wouldn't make so much people angry. Moreover we wouldn't need to remove those bindings if they were not saved in the user's settings if they haven't changed -- or if we could detect they haven't been changed.
Whatever, I hope I perhaps presented the thing a little better so you didn't only see the "backward compatibility" words? :)
Cheers, Colomban
[1] although we wouldn't need to since we rebind them to the default Scintilla bindings -- see we don't rebind the <Shift> variants.
Cheers Lex
Looking forward to read you :) Regards, Colomban
[1] https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3041948...
PS: This uses 2 new Scintilla (not yet released) commands to respect "smart home key" feature when dealing with display lines, so you'll need a patch for that too -- attached. PPS: 3rd patch is to make "move to start of display line" command respect the "smart home" feature, too.
On 29 August 2012 22:39, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 29/08/2012 02:34, Lex Trotman a écrit :
On 29 August 2012 04:02, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
I took a look at #3041948 [1] and did a prototype patch (attached) to fix it. Basically it's about the behavior of the Home and End keys regarding wrapped lines. We have configurable keybindings already, but they don't really make the editor display-line-friendly since they don't change the behavior of <Shift>Home and <Shift>End, aka selection extension.
Instead of repeating me, I'll quote the attached patch:
Add setting to make Home and End keys navigate in display coordinates
This cannot really be mapped using the keybinding because holding Shift together with Home or End is expected to behave exactly the same as without it but extending the selection; which is tricky to get using configurable bindings.
For this setting to behave correctly, the Home and End keys should obviously not be bound to any action, so the default bidings of Home and End should most probably be removed. Maybe the "Go to [display] line start/end" actions should be removed altogether now a global setting can be used to choose one behavior or the other; but they can also be kept but unmapped by default, which would allow a user to map another key to this action (like <Ctrl>A and <Ctrl>E to emulate a Bash/Emacs-like behavior).
Closes #3041948.
So, what do you think? Is this a correct way to fix this, or should we rather either add (4) separate configurable bindings for extending the selection to the start/end? Or should we add a trick to extend selection when <Shift> is pressed together with one of the current bindings (that's probably not a good idea in the (unlikely) case one binds one of these actions to <Shift>Something)?
Also, should we remove the bidings if we add that? Or should be just not bind them by default?
What about backward compatibility?
Hi Colomban,
Hey Lex,
Backward compatibility is absolutely essential, Geany must ship working as it does now !!!!!!!
I inserted other words than "backward" and "compatibility" in my mail, you know? :D
Hey Colomban,
My fingers typed that by themselves, they are very sensitive to any suggestion that they should re-learn their muscle memory :)
I don't see the point of going to the end of the "visual" line since that is just some arbitrary point at which the line is wrapped, it is unlikely to be significant, except you might want to add a line break there. Going to the actual start and end of the line is much more common IMNSHO, so it should be the default (as it is now).
This depends a lot on what's the displayed text I think. When writing programming languages yes, going to the visual EOL doesn't seem so useful; but if writing a long paragraph, you may want to move rapidly to a position that happens to be near visual EOL, so you might want to hit End.
There is a "might" multiplied by a "happens to be" in that paragraph, so its still very low probability that end of display line is useful.
The one use-case I can see for display line operation is editing million character single line HTML. Given that this is a small use-case I proposed the simplest and easiest to maintain solution, so those who insist on doing that sort of thing, can set Geany up how they want.
Moreover, since visual lines may only be different from logical lines when line wrapping is enabled, one might argue that most people don't care for programming languages since most people don't activate line wrapping on them.
Yep, which is why *most* of the use of home and end and the related select extend is physical lines, and the operation shouldn't change in the rare occasion when wrapping is turned on.
If a user prefers to navigate by visual line, fine, they can change the bindings as you said.
The best way of handling "extend selection to end of visible/real line" would be to also make those keybindings that the user can set, with defaults as now and <shift><alt>home/end for the extend visual. So again Geany works as now by default, the opposite behaviour is available, and users who prefer it can change the bindings to make it their default.
This is doable, but:
- it adds 4 new "useless" keybindings
Of course I would claim that we can ship with the the display line actions unbound but ymmv. :)
- somebody who wants to change to "display line mode" needs to change 8
bindings (well, 4 manually at least).
True if you want display line all the time, for the few times most people will need that, having separate bindings don't screw with their existing bindings.
I totally agree however it's a perfectly OK solution, and that it has the main advantage of not raising any other questions.
Don't underestimate the size of that advantage :)
However, first note that the patch I proposed do NOT change anything by default and WON'T break any compatibility. No evil here.
Was hard to tell, the commit message sounded like magic was happening, and I don't like magic, its never right, its brittle, hard to maintain and generally nasty. Also the comment mentioned removing the standard home/end bindings which I read as not being compatible. And any attempt to apply magic based on an assumption that the keys are still bound as default is dangerous, and removing bindings makes things inflexible.
The thing is that we bind Home and End by default [1], so those bindings would override the Scintilla defaults my patch sets; and thus would "break" the setting.
IIUC the problem is that home/end are Geany keybindings but we let shift/home and shift/end go through to Scintilla?
If thats the case then just having your setting code change the Scintilla bindings isn't enough, the Geany action code for home/end needs to check the setting each call as well and swap its behaviour. That way it will work no matter if the Geany code or the Scintilla code is called, ie if the key is bound or not.
In one sense we would do well to not depend on Scintilla keybindings without setting them ourselves, but too much work.
And here comes the compatibility question if we'd
like to avoid the issue. But see that even removing the bindings altogether would only affect people who actually changed it, e.g. 0.01% of the users maybe (no, I'm NOT saying we can shit on 'em) so even a break wouldn't make so much people angry.
So if we won't "shit on 'em" then we don't make a break :)
Moreover we wouldn't need to remove those bindings if they were not saved in the user's settings if they haven't changed -- or if we could detect they haven't been changed.
As I suggested above, the Geany code should check the setting and modify its behaviour appropriately and then no change needs to be made to the bindings. The problem really isn't the bindings, its changing what the actions do based on the setting, so put the test in the action.
Whatever, I hope I perhaps presented the thing a little better so you didn't only see the "backward compatibility" words? :)
Huh, what? You said something else? :)
Cheers Lex
Cheers, Colomban
[1] although we wouldn't need to since we rebind them to the default Scintilla bindings -- see we don't rebind the <Shift> variants.
Cheers Lex
Looking forward to read you :) Regards, Colomban
[1] https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3041948...
PS: This uses 2 new Scintilla (not yet released) commands to respect "smart home key" feature when dealing with display lines, so you'll need a patch for that too -- attached. PPS: 3rd patch is to make "move to start of display line" command respect the "smart home" feature, too.
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel