Brackets: Alt+numpad arrows inserts special chars on Windows

[danelkhen]

Pressing alt+shift+[down arrow]->[down arrow] causes special char to be added inside column mode, which ruins the entire selection. Happens in Windows OS, I think that the event needs to be cancelled so the OS won't handle it as well.

[redmunds]

@danelkhen alt+shift+[down arrow] is the shortcut for Add Cursor to Next Line, which creates a multiple selection -- is this what you mean by "special" chars? I'm not sure what you mean by "column mode" -- can you provide more details? Maybe some sample text as an example would help.

[RaymondLim]

@danelkhen What keyboard layout are you using? Also are you pressing right alt key when using alt+shift+[down arrow] combination?

[danelkhen]

Hi,
I'm using English - US layout, but also have Hebrew - Israel layout installed.
I'm pressing the left-shift+left-alt combination. If it helps, this but also occurs in other editors (notepad++), but doesn't happen in Visual Studio.

Column mode is brackets' column mode, I don't think that there's much more detail to give here. Here's a screenshot if it helps:

[RaymondLim]

Looking at your screenshot I'm guessing it has to do with custom cursor. Have you installed any custom one?

Update: What happens if you press shift+left/right arrow to convert multiple cursors to multiple selections? Do you still see the weird characters in your selection?

[danelkhen]

When you say cursor - do you mean mouse cursor, or the text caret? In any case I don't have either of them custom. What you see is a ASCII character, since the combination of keys included alt+2+2 (in keypad) - windows inserts a special char with ascii code number 22. Any other combination will generate a different char. And yes, it happens every time that the alt is pressed. You can try it yourself in this message editor - just press alt+2+2, or alt+shift+2+2 (left alt, left shift), release it, and you'll see the special char. As I said - I think that Brackets needs to tell the OS that it 'handled' the keypress event, and prevent the OS from handling it again.

[MarcelGerber]

Ah, so the problem only happens on Win, when pressing Numpad Down.

[danelkhen]

Ummmm... yeah, hence the title of the bug... :-)

[danelkhen]

It happens with any key alt+/shift+arrows combinations that generates a valid ascii char

[peterflynn]

Clarifying title.

Note: I can only reproduce this if Num Lock is off.

[danelkhen]

Yep, that's how the ascii code thing works in windows. (I always keep numlock off for quick navigation).

[ingorichter]

@RaymondLim could you please open a CM issue to track this? Thanks.

[RaymondLim]

I can reproduce it in Notepad or any editor that does not have shortcuts with those combinations. It is Windows default to let users input ascii characters by holding alt key down and pressing some numeric keys from numpad. In the case of Alt+Down arrow key, Windows is inserting a symbol representing ascii character 02 regardless of NumLock is on or off. Removing CM label since it has nothing to do with CM.

Arrow keys in Numpad have different keycodes from normal arrow keys. i.e. keycode for normal Down arrow key is 40, but keycode for numeric key 2 is 98. Currently, we're not handling those from numpad in Brackets shell and therefore these combinations are handled by CM as key input.
Since we define these combinations to let Brackets users to create multiple cursors and the shortcuts with normal arrow keys are handled in Brackets shell, should we also need to handle arrow keys from numpad in Brackets shell?

Update: This is FOL. I tried it in KeybindingManager.js to handle the shortcut using the numpad down arrow key and it works to add multiple cursors but as soon as you release Alt key Windows will insert those ascii symbols.

[peterflynn]

@RaymondLim I think the confusion is that, from the user's viewpoint, there _is_ a shortcut assigned to those keys. When you press Alt-Shift-NumpadDown, it invokes both our Add Cursor to Next Line command _and_ the Windows ASCII-entry at the same time. That seems wrong.

But we actually _are_ handling and recognizing the key already, and invoking any command always calls preventDefault() on the key event... so it's not clear what else we could do to veto the Windows default behavior.

[RaymondLim]

@peterflynn yes, you're right! I just update my comment and I think it is FOL. I wonder why someone would prefer to use Numpad arrow keys to the normal arrow keys with the extra effort to turn off the num lock.

[pthiess]

Closing as a FOL as @RaymondLim indicated.

[danelkhen]

Well Raymond I can explain why would someone use the keypad instead of arrow keys - in two words: productivity and speed. I don't need to turn OFF the numlock since for me it's never ON. Using the keypad allows me to use combine the usage of arrows with home/end/pgup/pgdown buttons to quickly navigate or select code, when shift/ctrl/alt modifier keys are in use as well (token skip, selection and column mode). I understand that brackets is written in js and doesn't have access beyond the browser capabilities, but I think that:

1. A bug should be reported to all browsers that do not allow to cancel this event by the OS
2. Since Brackets runs as an exe file, it might be possible to 'hack-in' this behavior into the browser bridge.

It could be also nice if it was at least possible to change the key bindings so this feature will work with another keyboard combination.

One more question - what does "FOL" stands for?

Cheers

[RaymondLim]

FOL = Fact Of Life.

[peterflynn]

Interestingly, it looks like Ctrl-Alt-Down (the shortcut Sublime uses for this) is not subject to the Alt key behavior. So if we changed shortcuts, this problem would go away. Any idea why we deviated from the exsiting de facto standard shortcut in this case?

However, I also tried configuring Sublime to use Shift-Alt-Down like we do, and it does not have this bug -- so it does appear that there's some way to block the event natively. My guess is it's a CEF/Chromium bug that calling preventDefault() on a key even in JS doesn't block this for you... (So it may not quite be a FOL, but it would be challenging to fix on our own _if_ we insist on keeping the shortcut we currently use).

[peterflynn]

@danelkhen It sounds like you can work around this by remapping your keyboard shortcuts to use Ctrl-Alt-Up/Down instead of Shift-Alt-Up/Down in the meantime.

[danelkhen]

That could actually really help, thanks @peterflynn !

[danelkhen]

Unfortunately, remap of column-mode action or any other navigation action is not possible using the Brackets Key Remapper extension.

[dwelle]

You can remap column-mode actions in keymap.json via edit.addCursorToNextLine, edit.addCursorToPrevLine, respectively (Brackets 1.0)

E.g.:

"overrides": {
    "Alt-Shift-0": "edit.addCursorToNextLine",
    "Alt-Shift-9": "edit.addCursorToPrevLine"
}