<![CDATA[NotePad++ 7.5.6 inserts ASCII control codes like "DC3" for Control-S WITHOUT any background dialogues open when Unix-LF (UTF-8 w/o BOM) format is used]]>Hi there,

As many of us know, Notepad++ has an old bug – never fixed even to this day – about corrupting texts with ASCII control codes when keyboard shortcuts are used if it has any dialogues open (not just search/replace one). The remedy for years is to close all the dialogues/windows.

However, I stumbled upon a new way that it manifests itself: if I work on a text file that is Unix-LF (UTF-8 without BOM) format, and I use an AutoHotkey script to catch myself pressing “Control+S” (vk53sc01F) to automatically call a syntax checker plugin JSLint on the file, Notepad++ (the newest, fully updated 7.5.6 version) inserts “DC3” ASCII control code in the text instead of just accepting it is a short-cut and saving my text.

Interestingly enough, if the format of the text is Windows-CRLF (also UTF-8 without BOM), this never happens, everything works as intended.

Is there a way to FORCE Notepad++ to never glitch again in this case? So far I am at a loss what can be done. And I do not even know how to ask the developers to fix this bug so they would actually see it and fix it.

Thanks in advance.

]]>https://community.notepad-plus-plus.org/topic/15803/notepad-7-5-6-inserts-ascii-control-codes-like-dc3-for-control-s-without-any-background-dialogues-open-when-unix-lf-utf-8-w-o-bom-format-is-usedRSS for NodeThu, 16 Apr 2026 14:02:46 GMTTue, 22 May 2018 06:10:42 GMT60<![CDATA[Reply to NotePad++ 7.5.6 inserts ASCII control codes like "DC3" for Control-S WITHOUT any background dialogues open when Unix-LF (UTF-8 w/o BOM) format is used on Tue, 22 May 2018 06:42:27 GMT]]>PARTIALLY SOLVED:

It turns out that NP++ executable process returns “ready” state to Windows API before it is actually ready as it still running plugin activity. In my case JSLint’s syntax check of Unix-LF (UTF-8 without BOM) files apparently takes longer versus Windows-CRLF (UTF-8 without BOM) files, and this is how NP++ ends up not being able to process “Control+S” as a short-cut to save the file, but as a text input that shows up as “DC3”, corrupting it. Thus the solution is to use “Sleep 1000” AutoHotKey command before generating “Control+S” key combination or to swap it with the call for JSLint syntax check.

However, why the underlying issue of NP++ allowing ASCII control codes to be inserted in the text is still not fixed, is still a question. At no circumstances NP++ should allow the corruption of texts by garbage.

]]>https://community.notepad-plus-plus.org/post/32396https://community.notepad-plus-plus.org/post/32396Tue, 22 May 2018 06:42:27 GMT