Hello, @troglo37, @coises, @peterjones, @dr-ramaanand and All, Préamble : @troglo37, on demand of @dr-ramaanand, I changed your initial title : Is There A Way To Ignore Letters With Accents When Searching? by this new title, which seems more acurrate : Is there a way to find both alphabets, with and without accents, when searching? Thank you, @dr-ramaanand, for reminding me of this interesting post, which uses a more general, but more accurate, definition of accented characters ! Indeed, an accented character , let’s say the é character, may be described as : The character é LATIN SMALL LETTER E WITH ACUTE, of Unicode value 00E9 The character e LATIN SMALL LETTER E, of Unicode value 0065, followed with the character COMBINING ACUTE ACCENT, of Unicode value 0301 Note that, in this second form, the letter e is the main character of an \X sequence and the accent(s), coming next, are the subsequent chars of this \X sequence ! So, the macro, described in my previous post, should be changed as : <Macro name="Global Search" Ctrl="no" Alt="no" Shift="no" Key="0"> <Action type="3" message="1700" wParam="0" lParam="0" sParam="" /> <Action type="3" message="1601" wParam="0" lParam="0" sParam="(?=\X)(.)|(?!\X)." /> <Action type="3" message="1625" wParam="0" lParam="2" sParam="" /> <Action type="3" message="1602" wParam="0" lParam="0" sParam="(?1\(\?=[[=$1=]]\)\\X)" /> <Action type="3" message="1702" wParam="0" lParam="640" sParam="" /> <Action type="3" message="1701" wParam="0" lParam="1609" sParam="" /> </Macro> And it means that : If the current character found is a single character OR the main character of a current \X sequence, it must be replaced with the string (?=[[=$1=]])\X, where $1 represents the current char If the current character found is an subsequent character of the current \X sequence, thus an accent, it must just be deleted as its main character has been previously taken in account So, let’s consider the following text, pasted in a new tab : C'est là, près de la forêt, dans un gîte, où régnait un grand capharnaüm, que l'aïeul ôta sa flûte et son bâton de son canoë C'est là, près de la forêt, dans un gîte, où régnait un grand capharnaüm, que l'aïeul ôta sa flûte et son bâton de son canoë Note that, within the first line, the accented characters are single chars whereas, within the second line, the accentued chars are unaccented vowels followed with an accent character If we apply our modified Global Search macro against the first line of this new tab, we get this regex : (?=[[=C=]])\X(?=[[='=]])\X(?=[[=e=]])\X(?=[[=s=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=à=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=p=]])\X(?=[[=r=]])\X(?=[[=è=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=o=]])\X(?=[[=r=]])\X(?=[[=ê=]])\X(?=[[=t=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=g=]])\X(?=[[=î=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=o=]])\X(?=[[=ù=]])\X(?=[[= =]])\X(?=[[=r=]])\X(?=[[=é=]])\X(?=[[=g=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=i=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=g=]])\X(?=[[=r=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=c=]])\X(?=[[=a=]])\X(?=[[=p=]])\X(?=[[=h=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=ü=]])\X(?=[[=m=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=q=]])\X(?=[[=u=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[='=]])\X(?=[[=a=]])\X(?=[[=ï=]])\X(?=[[=e=]])\X(?=[[=u=]])\X(?=[[=l=]])\X(?=[[= =]])\X(?=[[=ô=]])\X(?=[[=t=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=l=]])\X(?=[[=û=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=e=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=b=]])\X(?=[[=â=]])\X(?=[[=t=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=c=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=o=]])\X(?=[[=ë=]])\X Which does match the two lines of the new tab ! And if we apply our Global Search macro against the second line of this new tab, we get this regex : (?=[[=C=]])\X(?=[[='=]])\X(?=[[=e=]])\X(?=[[=s=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=a=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=p=]])\X(?=[[=r=]])\X(?=[[=e=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=o=]])\X(?=[[=r=]])\X(?=[[=e=]])\X(?=[[=t=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=g=]])\X(?=[[=i=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=o=]])\X(?=[[=ù=]])\X(?=[[= =]])\X(?=[[=r=]])\X(?=[[=e=]])\X(?=[[=g=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=i=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=g=]])\X(?=[[=r=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=c=]])\X(?=[[=a=]])\X(?=[[=p=]])\X(?=[[=h=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=u=]])\X(?=[[=m=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=q=]])\X(?=[[=u=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[='=]])\X(?=[[=a=]])\X(?=[[=i=]])\X(?=[[=e=]])\X(?=[[=u=]])\X(?=[[=l=]])\X(?=[[= =]])\X(?=[[=o=]])\X(?=[[=t=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=a=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=l=]])\X(?=[[=u=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=e=]])\X(?=[[=t=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=b=]])\X(?=[[=a=]])\X(?=[[=t=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=d=]])\X(?=[[=e=]])\X(?=[[= =]])\X(?=[[=s=]])\X(?=[[=o=]])\X(?=[[=n=]])\X(?=[[= =]])\X(?=[[=c=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=o=]])\X(?=[[=e=]])\X Which does match, also, the two lines of the new tab ! In conclusion, this method allows you to search for a stream selection of characters, regardless of the syntax of the accented characters within that selection ! Best Regards, guy038

@arnaud-derette said: I does not work in the operator 2 list either (or may be i need to do something more than just put § there ?) Like I said, because you want the § to not have spaces, like in parent§.D, it won’t work for you. § in operators 2 will only work if you can have spaces around the §

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

@M-Andre-Z-Eckenrode said: However, I am noticing an annoying behavior when exiting Notepad++ after having been using multiple instances of it. It’s pretty common for me to have at least two instances of NPP open, usually on two different desktops under Windows 10 x64. The second instance is normally opened with command line options -multiInst -nosession, and I always exit it before exiting the primary instance. but every time I try to exit the primary instance after having exited the secondary, the following message appears in a Yes/No dialog: “It looks like the configuration file for this plugin was edited during this session. Do you want to save the current configuration settings? (If Yes, the edited file will be overwritten.)” I see. I put in the code for that as a general thing I use in my newer plugins, so that if you ever want to edit the configuration file, you don’t have to use something other than Notepad++, or fuss around copying or renaming, to do it. But I didn’t think of your case. With multiple instances of Notepad++, both copies use the same configuration file. The configuration file keeps track of many things besides settings: history of what was used in the find and replace boxes, position of the dialog; I’m pretty sure that it always gets rewritten on every run. So the instance you close first writes to the configuration file, then the instance you close next sees that the timestamp on the file is different than the one it recorded when you opened it, and warns you that you have to choose between losing whatever changes you made to it (in this case, in the other instance of Notepad++) or losing whatever changes you made in this instance. Sorry about that. I really just didn’t think of people using two or more instances of Notepad++ and how this would interfere with that. I’ll work out a way to let you disable that feature/aggravation. Thank you for giving Search++ a try!

@guy038 said: 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 ). Autodetect is irrelevant when a byte order mark is present: Notepad++ always honors byte order marks. The only time autodetect matters is for a file with no byte order mark that doesn’t appear to be UTF-8 and doesn’t have an internal indication (like an HTML file with a <meta charset> declaration) of its encoding. With autodetect off, such files will always be read using the system default code page. With autodetect on, Notepad++ runs some heuristic tests to try to guess whether the file uses a different legacy encoding. When plugins access documents open in Notepad++ they necessarily use the copies Notepad++ has already loaded, so they “inherit” Notepad++’s encoding detection. The loaded copy will always be either in the system default code page (“ANSI”) or UTF-8. Notepad++ converts any document that isn’t one of those. (Any indication in the status bar other than ANSI or UTF-8 means Notepad++ has converted the document to UTF-8, and will convert it back to the indicated encoding when saving it.) If a plugin accesses files on disk without opening them in Notepad++ — as Search++ does for Search in Files, and as it appears MultiReplace does when searching in files — it’s up to the plugin to sort out the encoding. I’m not familiar with the code for @thomas-knoefel’s MultiReplace, but based on your tests, I suspect it doesn’t process UTF-16 correctly when searching in files. You could probably construct a minimized example and submit an issue if you were so inclined. 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++ ? Comparisons looked fine at first. I was running regular expressions with a lot of backtracking against thousands of files on an SSD. Then things fell apart when I tried a network share. Most of my testing has been “stress testing” rather than comparisons, but they point to the same problem. I understand the problem. Engineering a solution is taking some time. Your tests, with the inclusion of re-running the searches, demonstrate what is happening quite well. In the rerun tests, the files from your thumb drive were already cached by Windows. Those second tests show (roughly) how much time the actual searching took. (Notice that Search++ was faster there, because it uses multiple cores of your computer to search several files simultaneously instead of processing them one at a time.) The difference between the first and second runs is (roughly) the time it took to read the files from the thumb drive. That is where the current version of Search++ is just plain doing it wrong. I naïvely supposed that Windows was smart enough to “serialize” access to a device, like a USB drive, from different threads in a manner sensible for the device. Alas, it doesn’t work that way. However many threads your computer can run simultaneously, they’re all hitting the USB drive with requests for different files at the same time. Not only is that not any faster than single-threading them, it’s actually slower, because the controller in the drive is dealing with “too many” requests coming in all at once. The multi-threading I have works pretty well for an internal SSD. It also works if Windows has already cached the entire folder in memory. For everything else… it sucks. I’m working on solving that problem now. It’s slow going. There are a lot things you can “get by with” when single-threading that just blow up under one condition or another when multi-threading.