@guy038 said: I understood the small differences which occur in the MultiReplace search ( 27,112 - 25 ) matches in ( 833 + 2 ) files. But, I prefer, first, to study more closely the MultiReplace plugin, which is very powerful too and reply later to @thomas-knoefel. It concerns the encoding of 4 files which is not recognized properly and which occurs only when the Find in Files command is used. The Find All and Find in Docs commands, themselves, give correct results for these 4 files !? As best I can make out, like Search++, MultiReplace processes searches against documents open in Notepad++ using the copy of the document that Notepad++ has loaded into Scintilla. (I can’t really think of another way it could be done.) That means that for existing files, Notepad++ has already determined the encoding and either loaded it as ANSI or UTF-8, or translated it to UTF-8. (Notepad++ never sets Scintilla to use any encoding other than UTF-8 or the system default code page; anything else is translated to UTF-8 and translated back on writing.) So it’s no surprise that we’re both using the same encoding as Notepad++ for Find All and Find in Open Documents, because we’re just using the work Notepad++ has already done. I think MultiReplace uses an invisible Scintilla to process searches in files. It could be that it hasn’t entirely replicated the labyrinthine logic Notepad++ uses to determine the encoding of a file (including the effect of Preferences | MISC. | Autodetect character encoding). Search++ does not duplicate that logic either, but it approaches the problem in a different way. Rather than using an invisible Scintilla control, Search++ uses its customized version of Boost::regex directly on the data in the file buffer. So I never translate the file encoding to anything else. I do have to determine the encoding, though, as the choice of iterator for Boost::regex depends on that. There are limitations, not yet formally documented, to the way Search++ handles encodings for Search in Files: UTF-16 files without a byte order mark are not recognized as such. (They’ll be misread as something else.) 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. 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.) 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. The sad fact about file encoding is that in most cases there is no algorithmic way to be absolutely certain about what it is. (The exceptions are pure ASCII — but then, if any non-ASCII characters are introduced, there is no way to know how those should be encoded — and some file types, like HTML and XML, that can include a declaration of their own encoding, the declaration itself being in plain ASCII. Byte order marks are, in practice, another exception: they could occur in a legacy encoding, but they would be so uncommon at the start of a file that it’s safe to assume they are definitive, or the file has been purposely engineered to cause mis-detection.) I will probably improve handling of file encodings as Search++ evolves. I doubt that I will attempt to duplicate exactly what Notepad++ does.

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

@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.

@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.)

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?