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 Home and 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 A and 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 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 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&group_id=153444
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.
>From 5f82052cb7276bd8d1197651636a9c6ceae43f37 Mon Sep 17 00:00:00 2001
From: Colomban Wendling
Date: Tue, 28 Aug 2012 19:41:42 +0200
Subject: [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 A and E to emulate a
Bash/Emacs-like behavior).
Closes #3041948.
---
data/geany.glade | 31 ---
src/editor.c | 20 ++--
src/editor.h |1 +
src/keyfile.c|2 ++
src/prefs.c |6 ++
5 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/data/geany.glade b/data/geany.glade
index 675ffbc..54f396e 100644
--- a/data/geany.glade
+++ b/data/geany.glade
@@ -2693,6 +2693,23 @@
+
+Home and End keys operate on display lines
+False
+True
+True
+False
+Whether Home and End keys operate on logical or display lines.
+True
+True
+
+
+False
+False
+2
+
+
+
Disable Drag and Drop
False
@@ -2706,7 +2723,7 @@
False
False
-2
+3
@@ -2722,7 +2739,7 @@
False
