Rectangular selection mode initialization inserts garbage characters

[r0polach]

When I initiate rectangular selection mode by shift + alt + numpad_arrow_key,
geany puts some garbage characters into selected positions. This happens only
with numpad arrow keys (with num lock off), not with ordinary arrow keys.

This affect version 1.38. In geany 1.36 everything was ok.

[eht16]

Can you reproduce this with Scite?
I'm not sure but it could be a Scintilla issue (if this is an issue at all?).

[elextr]

The shift key is supposed to invert the lock keys, caps lock and num lock. So with num lock off you are typing Alt-Shift-[2468] not Alt-Shift-[down,left,right,up] so you will not get selection extension. Whatever Alt-Shift-[2468] is doing depends on what you or a plugin has defined those keys to be, for me it does nothing. Perhaps your 1.36 was GTK2 and that did not have the correct interpretation of the interaction between num lock and shift and now with 1.38 being GTK3 it has.

[r0polach]

I never heard of the idea that shift should invert num lock. And I think it is really not good idea,
because it is simply incompatible with any Shift+arrow combinations. E.g. here it suggest that
I should use Alt+numpad_arrow instead of Alt+Shift+numpad_arrow, which does not work of course.

But if this behaviour is part of GTK, it is not a topic to solve in this issue. Nevertheless it is possible
to tweak GTK configuration (for use with Geany on Windows) to turn this behaviour off? I.e. to enable
Alt+Shift+numpad_arrows to initiate rectangular selection without inserting garbage characters?

[nyamatongwe]

Windows interprets Alt+NumericKeypad keys as entering characters by their numeric values.

https://en.wikipedia.org/wiki/Alt_code

Scintilla can't prevent this from happening so the Win32 platform was patched to ignore numeric keypad keys with Alt.

https://sourceforge.net/p/scintilla/bugs/2152/
https://sourceforge.net/p/scintilla/code/ci/6950bccc71ce88158997b7cd9154541dfda6d52c/

This could be added to GTK on Windows but it actually stops what the poster wants because it disables the ability to use the keypad for rectangular selection. It would, however, be clearer and users can be directed to the true navigation keys instead of trying to use the numeric key pad.

[elextr]

@r0polach your OP didn't say Windows. My reply was for Linux.

An easy way to see what key sequences are being generated in Geany (after munging by the OS and GTK) is to use Edit->Preferences->Keybindings and try to set something to the mystery key sequence and see what GTK says (the code printed by Geany in the setting dialog comes from GTK). Using that on Linux I get:

Numlock	Resulting keycode
off	<Shift><Alt>KP_8
on	Shift><Alt>KP_Up

Maybe you can try it in Windows.

Not sure what happens on Macos.

@nyamatongwe thanks for the explanation. Certainly using the hard arrow keys is the best solution for keyboards that have them.

[r0polach]

Thanks all for information.
When I tried combinations in Edit->Preferences->Keybindings in Windows Geany,
it gives me <Alt><Shift>Up, <Alt><Shift>Left, etc. even for keypad arrows when num lock is off.
While caret navigation key combinations cannot be binded in this dialog, it probably use different
way of detection key combinations than this dialog. Or Windows take the action in this situation.
But GTK2 (Geany 1.36 for Windows) did somehow block it.

[elextr]

it gives me Up, Left, etc. even for keypad arrows when num lock is off.

Ok, so GTK3 on Windows behaves differently to GTK3 on Linux. The whole keyboard interpretation thing is really messy, GTK is trying to interpret keyboard signals to the functionality written on the keycaps depending on the keyboard model specified. That Windows hijacks some combinations just makes it worse.

While caret navigation key combinations cannot be binded in this dialog, it probably use different
way of detection key combinations than this dialog. Or Windows take the action in this situation.

Scintilla default keybindings are not modified by Geany so they happen because any key event not caught by Geany is simply passed unchanged to Scintilla, which is what would normally happen to <Shift><Alt>KP_Up. There has been discussion about allowing these bindings to be changed in Geany but nobody has needed it enough to do it.

In the keybinding dialog Geany has a keygrab on the dialog which is not present on the Scintilla widget and may have an effect, causing either Windows to not do the numeric entry thing, or its being ignored by GTK, anyway it does not seem to be seen in the dialog.

Normally any key combinations not defined in Geany are passed to Scintilla, so it appears to be seeing the selection extension keycode and the Windows numeric entry value which it quite reasonably takes as text to replace the selection.

Possibly the patch @nyamatongwe suggested applying to Scintilla on GTK on Windows is the best solution, it prevents replacing your selection by junk at the expense of removing the capability to use the keypad arrows to extend selection.