Hello, @coises and All, You said : There are limitations, not yet formally documented, to the way Search++ handles encodings for Search in Files: 1. UTF-16 files without a byte order mark are not recognized as such. (They’ll be misread as something else.) 2. UTF-8 files without a byte order mark that contain any invalid UTF-8 sequences will be processed using the system default (ANSI) code page. 3. Pure ASCII files are processed as UTF-8. (This doesn’t matter for Find, but I will have to review it when I implement Replace, since someone might include non-ASCII characters in the replacement text. I think there will have to be a user control to determine whether to promote ASCII to ANSI or to UTF-8.) 4. Files without a byte order mark that are not pure ASCII and contain any invalid UTF-8 characters are processed using the system default code page. No attempt is made to detect whether a different legacy code page is more likely to be correct, or is explicitly declared within the file. Thanks for this extra information ! FYI, during all my tests, the Autodetect character encoding option, in Settings > Preferences… > MISC, was checked and all the files, described in the P.S. section of my previous post, contain a Byte Order Mark ( BOM ). Here is the list of all UTF-16 files of my D: USB key •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | | | | Multi-Replace | Search++ / N++ | | BOM | File | Encoding | Matches 'Fi' | Matches 'Fi' | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | FE FF | D:\Plane_0_UCS-2_BE.txt | UTF-16 BE BOM | 2 | 0 | | FE FF | D:\Planes_0+1_UTF-16.txt | UTF-16 BE BOM | 2 | 0 | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | FF FE | D:\862_x64\plugins\NppExec\doc\NppExec\NppExec_HelpAll.txt | UTF-16 LE BOM | 0 | 31 | | FF FE | D:\Plane_0_UCS-2_LE.txt | UTF-16 LE BOM | 2 | 0 | | FF FE | D:\862_x64\plugins\Config\npec_cmdhistory.txt | UTF-16 LE BOM | 0 | 0 | | FF FE | D:\862_x64\plugins\Config\npes_last.txt | UTF-16 LE BOM | 0 | 0 | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• | | Total | | 3 Files / 6 hits | 1 File / 31 hits | •------------•--------------------------------------------------------------•-----------------•---------------------•--------------------• Notes : The correct results are reported in the last column My USB key also contains 49 UTF-8-BOM files ( EF BB BF ) correctly detected by all the search engines ! Now, based on my test, have you conducted any similar tests of your own, and have you found that searching with Search++ also takes longer compared to the native search in N++ ? Of course, I can run more tests myself, but I imagine your tests would be more valuable and might, perhaps, give you some ideas on how to increase the overall search speed with Search++ I’m really curious to hear your own observations ! Best Regards, guy038

@harry-brookes , @peterjones “the devil is in the details” And there are more details than I knew existed. The details have details. It’s easy for a naïve multi-threaded implementation to be slower than a single-threaded implementation, as was demonstrated when @guy038 ran a test of my search on a folder on a USB stick. I’m working now on improving it. It’s incredible how many ways there are to shoot yourself in the foot with multi-threading. I’ll feel validated if I can come up with something that is sometimes better than single-threaded and never worse than single-threaded. It remains to be seen if I can do it.

@Troglo37 said: Another issue I’ve been dealing with is letters with accents. Many times I’ve searched for a name and couldn’t find it. Later on, I realized that it was because the name had an accent. So, I’ve had to painstakingly go through some of the names I have typed in and change the letters. I want to be able to copy and paste names without worrying about accents, and preferably have the correct spelling of the person’s name if they have accents. It has been requested before. At present there is a way, but not a convenient way. To search for a name like René you can use the following form as a regular expression: [[=r=]][[=e=]][[=n=]][[=e=]] Yes, it’s a pain in the butt. Maybe someday someone will make a simple switch for it. (Note to self: my still-in-progress Search++ plugin should have that as an option for plain text searches.)

@Sam-Fourie , It’s been suggested before, as in issue #17430. The developer stated explicitly: It’s not my intesion to “lock” the document by using “Pin a document”. It’s just a way to make the documents grouped in front so users find them more easily. Checked with MS VC Studio, their behaviour is the same as Notepad++, and I think it’s the right behaviour. It works the way the developer wants, and he has rejected the suggestion to make it work the way you want. update: I’m not saying it’s not a good idea. Just that the developer (who is the final decision maker) is the one you’d need to convince. And, given that he’s already rejected the idea, you’d have to come up with something more than “I really want it” to convince him otherwise (and it would have to be posted in the issues tracker, presumably as a reply to the issue I linked, not in the user Community).

Seems they decided that it they couldn’t be the heroes, rhat they would be the villains.

For anyone who wants to get rid of that annoying “This file has been modified… Do you want to reload it…” prompt/dialog box, do the following: Go to Settings Click Preferences Click MISC. Under “File Status Auto-Detection” click Disable from the drop-down menu Close

User Manual has been updated: Renamed header to “shortcuts.xml Security” and includes mention of Macros as well: https://npp-user-manual.org/docs/config-files/#shortcutsxml-security added Macros Security on the macros page: https://npp-user-manual.org/docs/macros/#macro-security added a paragraph linking to the “shortcuts.xml Security” page in the Running External Commands page: https://npp-user-manual.org/docs/run-menu/#security-is-your-responsibility

@M-Andre-Z-Eckenrode said: Possible v8.9.7 bug? I wouldn’t call it a bug. v8.9.7 intentionally made sure that running a Macro performed the same HMAC check as running a Run menu entry. If your PythonScript runs a menu command (either a macro or a run-menu command, especially), it would also trigger that check. Or, if you hadn’t used any of the intervening v8.9.6.2-4 subversions, then your HMAC would never have been updated, and Notepad++ would demand a single validate to your custom shortcuts, becaus of your PythonScript shortcut.

@PeterJones I was looking at style for CDATA instead of SGML, so that explains it. Thanks a lot for the help!!

Ah ok. So just noticed this has been implemented after updating to 8.9.7. How do I get around the dialog coming up “security information for shortcuts.xml is missing in config.xml” when I deploy this to multiple computers? I have a “master copy” of a portable installation on a network drive, then update that whenever a new version comes out. There is a batch file on a “client” PC that basically copies that folder from the network drive to a local drive on the client. So every client, whenever they first use a macro, gets this warning and has to validate the shortcuts.xml file. How do I stop this from happening, i.e. how can I make the shortcuts.xml file “trusted” in the master copy on the network drive, so it appears trusted on any other client that happens to download it?

@Elayne-T , Do you have your ?-menu’s Debug Info? Do you have plugins in Notepad++ that might be doing something in the background? (Maybe a plugin has popped up a dialog, but because they didn’t code it right, the dialog doesn’t go in fron of Notepad++'s always-in-front.) Do you have a file open that requires Admin privileges to write/save? If so, maybe Windows has popped up the UAC, but it didn’t get to take your full screen like it normally would (the UAC shield icon would be on your taskbar if it’s an issue with the UAC) Do you have anything other than Notepad++ and your browser running? Do you have any applications like AutoHotKey, which assign global hotkeys that maybe it’s interpreting some sequence of keystrokes you are using to Does your browser have any extensions/plugins that might be trying to steal focus away from Notepad++? It will be easier to replicate and find if you give as many details and pieces of relevant information as possible, otherwise something as nebulous an unrepeatable as this is going to be difficult to find. update: one more idea: in the older posts, they mentioned that they’d click in Notepad++ to activate, then after a few seconds of typing, the focus would be lost. Is that the case for you? If so, did you leave the mouse pointer somewhere over the Notepad++ window when you started typing? Or does the mouse pointer start drifting off accidentally (maybe you bumped the mouse while typing, or it gets shaken while you type fervently)? Or does the mouse pointer get moved off intentionally (for example, when I was experimenting with always-on-top, I would move the mouse pointer back over the Chrome window, then use the scrollwheel to scroll the browser tab without clicking in the browser). If your mouse pointer is back to being over the browser (or some third app), maybe something in that other app grabs focus when you leave your mouse lingering over it (I know that some linux GUI will give apps focus whenever the cursor hovers over them, even if they haven’t been clicked to the foreground… maybe some other app – your browser or something else – has given itself such a feature, even on Windows.)

@Coises said: What is really means is, when Notepad++ opens an existing file that contains only ASCII characters, it should treat it as UTF-8 rather than as ANSI. Yeah, so for example: “Treat ASCII-only files as UTF-8 (instead of ANSI)” or something similar could be a more clear wording for the option. Which, for me, raises the question: Why is this only available when UTF-8 is the default encoding for new files? It would add a bit more flexibility to the user, but on the other side it seems very unlikely to set this option if you don’t want UTF-8 as default. So I guess it could be a preventative measure that the user doesn’t set any confusing options.

because it appears those actually return from the enum UniMode, which is enum UniMode {uni8Bit=0, uniUTF8=1, uni16BE=2, uni16LE=3, uniCookie=4, uni7Bit=5, uni16BE_NoBOM=6, uni16LE_NoBOM=7, uniEnd}; according to the source code. In N++ commit 8149f72 in v8.8.8 (Nov 2025), uniCookie has been renamed as uniUTF8_NoBOM inside the N++ source. Thus, I just put in PythonScript Issue #421 to request that there’s a BUFFERENCODING.UTF8_NOBOM, either as replacement or alias of the old meaninglessly-named BUFFERENCODING.COOKIE … I don’t know if it will happen, but at least the request is in. :-)

@ThosRTanner said: This doesn’t seem terribly useful for an installation package though. This is exactly my use case: I download the zip archive end selectively extract only changed files. Some of the files in my installation I explicitly do NOT want to get overwritten. In the end it is really just a matter of taste. And I really appreciate the possibility to choose my desired format. From this I support the current situation, that both format are presented for download.

@guy038 Merci beaucoup!

FYI: Notepad++ v8.9.7 RC2 is available now: https://github.com/donho/notepad-plus-plus/releases/tag/RC2

Another example can be seen at https://community.notepad-plus-plus.org/topic/27601/with-the-help-of-a-regex-how-to-find-code-preceded-by-a-only-if-code-is-absent-between-style-and-style-in-the-css-section-which-is-below/4

@rafaello , IANAL, and I don’t own the trademark, but with your clarifications and updates, I believe you’re probably not violating the trademark (IMO). It’s good to see someone who is willing to accept such feedback (rather than digging in your heels for a while, like happened with the aforementioned fork).