Notepad++ enters unwanted invisible (ASCII 0–31) characters

benelaci

Hello,

If I press a CTRL+Shift+[letter] key combination, an invisible ASCII character is entered, the code of which is the alphabetical position of the letter pressed (unless it’s a keyboard shortcut assigned to something else).

Example:

CTRL+Shift+A enters SOH (ASCII code: 1)
CTRL+Shift+C enters ETX (ASCII code: 3)
CTRL+Shift+E enters ENQ (ASCII code: 5)

The related part of the ASCII table:

Code | Name
-----------
  00 | NUL
  01 | SOH
  02 | STX
  03 | ETX
  04 | EOT
  05 | ENQ

I really want to disable this, because whenever I accidentally press a key combination like this while coding, it causes a great deal of headaches.

Alan Kilborn

@benelaci

There are some techniques for doing this, found HERE.

Alan Kilborn

Since this seems to be sort of a FAQ, I’ve begun a “fix” to Notepad++ source code to be able to control this behavior; see HERE for the “issue” and then see the FIX.

Coises

@benelaci said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

I really want to disable this, because whenever I accidentally press a key combination like this while coding, it causes a great deal of headaches.

From the View menu, select Show Symbol | Show Control Characters & Unicode EOL so that there is a check mark beside that setting.

That will cause those characters to be displayed as black boxes with the control code mnemonic inside instead of being invisible. Once you can see them, you can correct them as you would any other typing mistake.

Coises

@Alan-Kilborn said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Since this seems to be sort of a FAQ, I’ve begun a “fix” to Notepad++ source code to be able to control this behavior; see HERE for the “issue” and then see the FIX.

Can this be serious? What about Ctrl+Shift+S or Ctrl+Shift+W? Isn’t a typing mistake as likely to be one of those as it is to be an unassigned combination? If this is a persistent problem, I don’t see an alternative to improving one’s typing skills, unless you want to disable all keyboard shortcuts along with the control characters.

The sensible fix for the occasional error is to enable Show Control Characters & Unicode EOL (if that’s not the default, it surely should be), so the mistake can be seen and fixed like any other typing error.

Alan Kilborn

@Coises said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Once you can see them, you can correct them

It’s true…but saving a step would be even better.
And having to deal with this over and over in this forum would stop. :-)

mkupper

@Coises said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Can this be serious? What about Ctrl+Shift+S or Ctrl+Shift+W? Isn’t a typing mistake as likely to be one of those as it is to be an unassigned combination? If this is a persistent problem, I don’t see an alternative to improving one’s typing skills, unless you want to disable all keyboard shortcuts along with the control characters.

I believe the goal here is to allow the user to easily define how all unhandled keystrokes get processed.

At present there are a small number of possible keyboard combinations that are not mapped. Using them adds strange characters in your document.

By default, Ctrl+Shift+S is mapped to File / Save All (which saves all tabs that are currently in the modified state), and Ctrl+Shift+W is mapped to Edit / Line Operations / Split Lines (which I think of as word wrap). As they are mapped you won’t end up with DC3 or ETB codes in your documents.

PeterJones

@mkupper said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

By default, …, and Ctrl+Shift+W is mapped to Edit / Line Operations / Split Lines (which I think of as word wrap).

You’ve changed that shortcut, because that’s not the default.

In a fresh portable unzip, Edit / Line Operations / Split Lines is Ctrl+I (where “I” is the opposite of “J” from Join, the next command). And I confirmed it in the source code default keystrokes mapping.

This clarification is irrelevant to your point, which is still valid, and summarized by the statement: Any shortcut that is mapped will not be affected by Alan’s Control-Character trap; his proposed trap only affects Control Characters whose keystrokes are not mapped to something else.

Alan Kilborn

@mkupper said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

I believe the goal here is to allow the user to easily define how all unhandled keystrokes get processed.

At present there are a small number of possible keyboard combinations that are not mapped. Using them adds strange characters in your document.

@mkupper is correct.

The proposed “fix” works by trapping out a WM_CHAR message, i.e., not allowing it to reach Scintilla when Scintilla is about to put a (control) character in your document. Since assigned shortcut keys don’t put characters in your document, they clearly work via another mechanism, not WM_CHAR. So…TL;DR: No problem. :-)

mkupper

I had forgotten that Ctrl+Shift+W comes from the days of using the TextFx plugin. Once Notepad++ added the TextFx functions I was using I reconfigured the keyboard shortcuts to keep my fingers happy.

guy038

Hello, @benelaci, @alan-kilborn, @coises, @mkupper, @peterjones and All,

@alan-kilborn, in your last post, you said :

Since assigned shortcut keys don’t put characters in your document

Now, Alan, what about macros which could just add some chars, in current document, and which would be bounded to a shortcut, too ?

May be, I do not exactly understand the whole problem !

Best Regards,

guy038

Alan Kilborn

@guy038 said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Now, Alan, what about macros which could just add some chars, in current document, and which would be bounded to a shortcut, too ?

I had said:

assigned shortcut keys don’t put characters in your document

I meant that when a keycombo (e.g. Ctrl+e) is assigned to a command, pressing Ctrl+e won’t put a Ctrl+e character in your doc. Now, the macro itself could put text in your document, of course, but that’s unrelated to invoking the shortcut with its shortcut key.

Also, if control characters are filtered out, pressing them when recording a macro won’t record them. But if you hand edit a macro and put a control character in the text of the macro in a 2170 message, it WILL then put that control character into the document when the macro is run.

cezar-mp

@Alan-Kilborn said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Since this seems to be sort of a FAQ, I’ve begun a “fix” to Notepad++ source code to be able to control this behavior; see HERE for the “issue” and then see the FIX.

Hey guys, good morning.

I’ve read the thread and I’m not sure still if the problem was addressed or how to address it…

Can someone tell me if this got fixed and in which NP++ version?

Thanks!

Alan Kilborn

@cezar-mp said in Notepad++ enters unwanted invisible (ASCII 0–31) characters:

Can someone tell me if this got fixed and in which NP++ version?

It’s “fixed” in 8.6.5, which, as of this writing, isn’t actually released YET.
To turn it on, checkmark the box for:

Settings menu > Preferences… > Editing 2 > Non-Printing Characters: Prevent control character (C0 code) typing into document

cezar-mp

@Alan-Kilborn cool man!

Thanks for the feedback! Can’t wait to update to 8.6.5 then!

You have a good one!