Issues with "Scintilla commands" keyboard shortcuts

Mikhail V

I am removing some keyboard shortcuts via the “Shortcut mapper” menu.
I have done this succesfully for “Main menu” commands tab.
Then I went to “Scintilla commands” and removed some as well.

I have removed “SCI_NEWLINE” command bindings, which was bound to “Enter”
and “shift+Enter”. (I’ve removed both shortcuts).
Now I have some weird problem: the enter key still works, but it works not as
previously - it does not follow autoindent setting - it just inserts newline.
(My expectation was that it will not work at all BTW, so I made it out of curiousity)

And I cannot set the shortcut back. How to do it without reinstalling
N++?

I have found some related options in “shortcuts.xml” (in the last section):

…
<ScintillaKeys>
<ScintKey ScintID=“2178” menuCmdID=“42002” Ctrl=“yes” Alt=“no” Shift=“no” Key=“45” />
<ScintKey ScintID=“2451” menuCmdID=“0” Ctrl=“no” Alt=“no” Shift=“no” Key=“35” />
<ScintKey ScintID=“2453” menuCmdID=“0” Ctrl=“no” Alt=“no” Shift=“no” Key=“36” />
<ScintKey ScintID=“2455” menuCmdID=“0” Ctrl=“no” Alt=“no” Shift=“no” Key=“0” />
<ScintKey ScintID=“2179” menuCmdID=“42005” Ctrl=“no” Alt=“no” Shift=“no” Key=“0” />
…

But I can’t find out what Keys=“” and ID’s numbers mean, is there some human-readable
code table for this?

Does any body know how to restore the SCI_NEWLINE key at least ?
(hopefully it will help to restore the behavior of N++)

Also, if this happens - is this a global issue? should there be some restriction or info
about some key bindings should not be touched?

Mikhail V

Ok I have solved this.
So I have found a document with these ScintID message codes:
https://scintilla.org/CommandValues.html

Then I searched that document for “newline” and it was:

2329 NewLine Insert a new line, may use a CRLF, CR or LF depending on EOL mode.

Then I opened my “shorcuts.xml” and just removed the line with this ScintID.
So the idea is to remove the corresponding definition from “shortcuts.xml” to restore the default.
(I have figured it out on a separate fresh copy of NPP and looking into xml while changing one shortcut)

PS:

Still, IMO this is an issue with the Shortcut mapper - it should not allow un-binding
that leads to such results - any user can accidentally do that.

To reproduce this issue:

go to Scintilla commands tab in the Shortcut mapper,
choose SCI_NEWLINE
click remove (it wil remove one command)
for the command left - Change the key binding to None and apply

Scott Sumner

@Mikhail-V

the enter key still works, but it works not as previously - it does not follow autoindent setting - it just inserts newline.

Unmapped keys merely insert into text their equivalent values. For example, ctrl+e (if unmapped as it is by default) will insert a ctrl+e character in the text (you’ll see a black box with ENQ in it). Enter is no different, really, it’s equivalent is a line-ending character(s) insertion. I suspect when Enter is tied to a “command”, SCI_NEWLINE in this case, that “extra processing” is done, and this is controlling the auto-indent.

And I cannot set the shortcut back

You have a real problem there! :-)

Does any body know how to restore the SCI_NEWLINE key at least ?

In a default install, I see this in shortcuts.xml:

    <ScintillaKeys />

After doing what you did and removing the SCI_NEWLINE keys, I then see this:

    <ScintillaKeys>
        <ScintKey ScintID="2329" menuCmdID="0" Ctrl="no" Alt="no" Shift="no" Key="0" />
    </ScintillaKeys>

So I suspect that you will also have one or more 2329 lines…if you remove them, I think your SCI_NEWLINE functionality will return.

is there some human-readable code table for this?

Well, there’s the source code! :-D
And maybe have a look here: https://notepad-plus-plus.org/community/topic/12576/list-of-all-assigned-keyboard-shortcuts

Mikhail V

LOL we have posted at the same time. Interesting - I saw my post marked with “1 minute ago” and your with “5 minutes ago” but mine is on the top :-)

So after your explanation about Enter key - it makes sense to me finally what was going on.
so it explains the behavior. But it may be frustrating because it kind of works but inserts CR only (so one may be spawning wrong line endings without even noticing it)

And the issue or I’d even say a bug - is that I cannon bind to Enter again - when I choose Enter in the key list, the Apply button is still inactive (grayed out).

Also I have noticed that if I bind anything in Scintilla commands to Alt+letter - the commands also open the Menus, e.g. Alt+E runs the command AND opens the Edit menu - that is really weird.

Scott Sumner

@Mikhail-V

I saw my post marked with “1 minute ago” and your with “5 minutes ago” but mine is on the top

Yes, I’ve seen this happen often…very odd.

…but inserts CR only (so one may be spawning wrong line endings without even noticing it)

Inserting CR only is ESPECIALLY BAD…I guess the “extra processing” I mentioned before checks the current line-ending type and inserts the correct thing (when this is mapped to SCI_NEWLINE).

And the issue or I’d even say a bug - is that I cannon bind to Enter again - when I choose Enter in the key list, the Apply button is still inactive (grayed out).

My experimenting showed the same behavior, so I would agree it is a bug. A bad one, for several reasons…

Also I have noticed that if I bind anything in Scintilla commands to Alt+letter - the commands also open the Menus, e.g. Alt+E runs the command AND opens the Edit menu - that is really weird.

Yea, this has come up before. It’s unfortunate. :-(

Scott Sumner

@Mikhail-V

So a couple of more notes from the earlier discussion:

Never stated, but hinted at: The entries for the Scintilla (and other) commands in shortcuts.xml are only overrides to the default keymapping. So when N++ starts up, it configures all mappable commands with their default keycombinations, and then applies any changes that are specified in shortcuts.xml. That’s why I said that a default install has an empty section for Scintilla keys, and when I made a change (removing Enter and Shift+Enter), then something actually appeared in the Scintilla keys section. Kind of odd, you delete something, and something appears where there was nothing… And one more thing: If Key=“0” in shortcuts.xml, that means the command has NO keymapping; the default keymapping (if any) is thus removed (since, remember, this is an override).
Regarding the Alt keys activating the File | Edit | Search, etc. menus, there IS a way around that; have a look at the technique presented here: https://notepad-plus-plus.org/community/topic/13762/disable-menu-activation-for-a-shortcut . If you implement that then you should be able to assign a command to, e.g., Alt+e and have it run unmolested.

Mikhail V

Thanks for the info, Scott. I think the issue with “Enter” binding should be reported if it is not yet been.

As for avoiding Alt+letter menu invocation, I solved this by defining Pythonscript scripts for some commands and bound them to Alt+letter keys.
For example I have a one-liner script for SCI_LINEDUPLICATE:

editor.lineDuplicate()

I assigned it to Alt+F and luckily it works without invoking the menu.
Yes it’s maybe strange to recommend as a general solution and adds overhead -
but I have already redefined many commands by custom scripts anyway so
for me feels totally ok.

Scott Sumner

@Mikhail-V

I think the issue with “Enter” binding should be reported if it is not yet been.

Yes, sure, go ahead and report it if it isn’t already an issue.

I assigned it to Alt+F and luckily it works without invoking the menu

Okay, now that is odd…but nice for what you need at the moment!

…maybe strange…and adds overhead…for me it feels totally ok.

It is totally okay…any “overhead” is meaningless…plus you are ready when editor.lineDuplicate() doesn’t meet your needs in all cases…you already have a script file started…for your “enhancements”! :-D