[Geany-devel] Logical vs. display line movements -- answering #3041948

Wed Aug 29 12:39:41 UTC 2012

Le 29/08/2012 02:34, Lex Trotman a écrit :
> On 29 August 2012 04:02, Colomban Wendling <lists.ban at 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&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.
>>