AutoHotkey: Ctrl+Shift+M adds blank line instead of triggering function

[Mister Mech]

I have an AutoHotkey function (Ctrl+Shift+M or ^+m) that has been working fine for several days. For some reason, it stopped triggering my function yesterday and started adding a new blank line instead. I’m pretty sure I accidently activated something because it went from working to not working while I was editing the AHK file in Notepad++.

I think it has something to do with Control Characters because Ctrl+Shift+B types STX and Ctrl+Shift+E types ENQ.

Also, there’s only one AHK script running and the trigger is only used once.

Thanks for any help.

[PeterJones]

@Mister-Mech ,

I am guessing the problem is on the AHK side, not Notepad++'s side.

When Notepad++ receives a Ctrl+... signal, it looks through its own shortcut map; if it finds nothing, and if the Ctrl+... sequence resolves to the upper or lowercase version of an ASCII control character, Notepad++ will insert that ASCII control character. Since Ctrl+M or Ctrl+Shift+M map to the carriage return character, if Notepad++ receives a raw Ctrl+Shift+M and cannot find an internal shortcut, it will insert the carriage return character.

Because of that behavior, and the fact that you are getting a newline when you try Ctrl+Shift+M, I am concluding that Notepad++ is receiving that sequence raw, from which I infer that your AHK is no longer intercepting Ctrl+Shift+M properly.

I could be wrong. But the data you have presented makes me think that’s the likely culprit.

[Alan Kilborn]

With default settings, Notepad++ will find the Mark command mapped to Ctrl+m. What didn’t occur to me is that Shift+Ctrl+m will behave as an unmapped Ctrl+m will, and thus will insert a carriage-return into the user’s document. :-(

Similarly, Ctrl+j is mapped by default to Join Lines, and that’s great because an unapped Ctrl+j will insert a line-feed into the user’s document. But…Shift+Ctrl+j will do this, again unknown and unwanted by the user. :-(

The bottom line is that this is a means for document “corruption” to occur, and it is a bit insidious, because this will be most often silently and unknowingly to the user. Think: Fat-finger one of these combinations when you’re going for another.

I don’t know why Scintilla ever thought it a good idea to allow Ctrl+m and Ctrl+j (and by extension the shifted versions) by default to insert these characters, when Scintilla knows the line-ending type for a document and should not violate that line-ending type (but there are also other ways it will do this, sigh…).

Perhaps the best avoidance workaround for this would be for Notepad++ to find commands in the default keymapping to bind Shift+Ctrl+m and Shift+Ctrl+j to.

[mpheath]

@PeterJones

I asked at Scintilla about Ctrl+M and the reply:

Carriage Return is Control M (0xD == 13). Entering control characters is sometimes needed because they have meaning in the language of the file being edited.

When Scintilla receives keystrokes that are not assigned to commands, it inserts the value, so Ctrl+M or Ctrl+Shift+M will insert the Control M value, 0xD or CR. Ctrl+Shift+C inserts ETX (3, Control C). This is the same as pressing the ‘k’ key and seeing ‘k’ in the text.

If you don’t want a key to insert its text value then assign it to a null command like SCI_NULL https://www.scintilla.org/ScintillaDoc.html#SCI_NULL .

It is up to the application, or the user to use the default key combination value, set a command or set the key combination to null. This is by design with Scintilla.

I consider that Ctrl+M may have caused issues with me before so setting these key combinations to null seems good for my use. Nothing like wasting time debugging an issue and finding out that some invisible inserted character accidently messed things up. If I want to add one of these invisible characters, find and replace comes in handy and is done intentionally.

So, looks like Peter’s explaination is close enough to hitting the bullseye so as to deserve a chocolate chip cookie. :)

[Alan Kilborn]

@mpheath said in AutoHotkey: Ctrl+Shift+M adds blank line instead of triggering function:

Carriage Return is Control M (0xD == 13). Entering control characters is sometimes needed because they have meaning in the language of the file being edited.

For Ctrl+m, this is just dumb. Scintilla has a history of justifying their behavior in ways like this. It’s like they get a question, and they think, “hmm, yes, our behavior is dumb, but let’s come up with some possibility with how it makes sense…”. IMO only, of course. This is especially true with something like the line-ending control characters – a better question for Scintilla might have been why they allow violation of a file’s line-ending type (where I’m sure the answer would be “some users need that”).

Ctrl+Shift+C inserts ETX (3, Control C). This is the same as pressing the ‘k’ key and seeing ‘k’ in the text.

Really? Another weaselly answer out of Scintilla; I suppose because it suits their purpose to answer that way, and in some small (non-zero) percentage of use cases it is probably needed. How many users in today’s environment would benefit from an ETX inserted in their document? As to k, well, obviously.

It is up to the application, or the user to use the default key combination value, set a command or set the key combination to null. This is by design with Scintilla.

And that’s fine, even if IMO it isn’t the best (default) design. Notepad++ code could certainly set the functionality to null for unassigned keycombos, but for whatever reason it chooses not to.

I consider that Ctrl+M may have caused issues with me before so setting these key combinations to null seems good for my use.

Are you saying you’d like this to happen, or you have a method for doing so currently?

BTW, there’s a PythonScript for preventing such control character input, available HERE.

[Mister Mech]

@PeterJones
You were right! Thanks for the info, it helped a bunch.

[Mister Mech]

Yeah, it turned out to be the unmapped shortcuts. Thanks to everyone for the detailed explanations. It helped with this and it will help in the future.