@guy038 said: I’m actually really surprised by Search++'s performance compared to Notepad++, especially when the search involves a complex regular expression. ( 0:16.36 vs 2:08.20 ! ) Please, note that the USB flash drive I used for my test is a fairly old one with a capacity of only 512 Mb, which may not be well-suited for multithreading and would explain the poor results with Search++ In any case, I assume you’re now confident in Search++'s overall performance ! I don’t entirely trust my own results. Why did my USB search in Search++ for the take longer than the search for a([^\r\n])[^\r\n]*b\1? Either the test data is erroneous or spurious, or Search++ is screwing up access to the USB in some way that’s causing it to “choke” and lose performance (what I suspect happened in your test). I’m still trying to work out how to avoid that happening without hurting the performance when reads are fast. To the best of my knowledge, Notepad++ is entirely single-threaded. It’s only ever doing one thing at a time. An i9-9900K can run sixteen threads simultaneously. So for CPU-heavy workloads (complicated regex searches) with lots of files, it’s not at all surprising that a multithreaded approach could be almost eight times faster. Thirteen times faster running a([^\r\n])[^\r\n]*b\1 against an SSD is pretty satisfying, though. :-) I’m probably getting additional gains from using memory-mapped I/O and running Boost::regex directly against the data the operating system maps into memory, while Notepad++ loads every file into a buffer, and from there into an off-screen Scintilla, before running the search through Scintilla’s API instead of directly with Boost::regex. It’s useful to have tests like yours. I won’t be able to test anywhere near all the situations that can occur. What happens when someone searches a OneDrive folder and not all the files are up-to-date? What happens when someone searches a drive that’s mounted over a VPN? What happens when the cat knocks the USB connector loose in the middle of a search? The worst case for all these is that the whole thing either crashes and takes Notepad++ down with it, or locks up and makes the user terminate Notepad++ with task manager — losing any unsaved work in progress. I don’t want to let that happen. I still have a lot to do to “harden” this against things that can go wrong. And that’s not even starting with Replace yet.

The Python script I posted is expected to handle single byte errors from UTF8 decoding. Asian languages can be 2 byte for ANSI and so the script may need to get the following byte too to decode both bytes properly. Probably will not find recovery tools and the like that will fix mixed encoding errors as the solution in some cases might be worse then the problem though in this case tested OK. Once saved, then there might be no going back and so creating a backup before the operation would be wise. Inspect the results to confirm is OK.

@guy038 Merci beaucoup!

@PeterJones Worked perfectly, thank you.

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, at the same time, 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 French 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 a copy of 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 a copy of 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

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

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

Hi, @dougk.az, @peterjones and All, Oh, yes, Peter, you’re perfectly right ! But I must be a little tired from this heat wave. Since June 22, in the room where my desk is, even with a fan, the temperature has usually been between 29 °C and 30.5 °C. It’s awful ! BR guy038 Oh ! Now, I also realized that @dougk.az never spoke about the form feed ( FF ) characters, of code \x0C but spoke about the line feed ( LF ) chars, of code \x0A As I said above : really tired by heat !!!

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

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

Hello, @murraysobol, @peterjones and All, I corrected, in my first post to @troglo37, the spelling mistake on the word shortcuts.xml and rearranged a few lines to make my description more precise ! Of course, @murraysobol, it’s better to use the second version of my macro. Note, however, that this macro generally replaces a fairly short piece of text with a rather long string of characters ! Therefore, you may need to change a default setting in the Search section of Preferences... if the resulting regular expression becomes too long ! For example, in my last post to @troglo37, the two lines of the test contains, respectively, 124 and 135 chars and the resulting regexes contains, both, 1,612 chars ! So, go to Settings > Preferences... > Searching section. Then, in the part When Find Dialog is Invoked, move to the Max Characters to Auto-Fill Find field from Selection option and modify the default 1024 value to a greater value. Personally, I use the maximum 16383 value ! However, it’s obvious that your initial selection must be as short as possible This macro will be used mainly to get the different spellings of names or surnames ! An exemple with this INPUT text, below : Our friends Šarūnas, Đorđe, Ørjan, Paweł, Ștefania, Ángel and Uğur had already left Our friends Sarūnas, Đorđe, Orjan, Paweł, Ștefania, Ángel and Uğur had already left Our friends Šarunas, Đorđe, Ørjan, Pawel, Stefania, Ángel and Uğur had already left Our friends Šarūnas, Dorde, Ørjan, Paweł, Ștefania, Angel and Ugur had already left Now if I copy, at random, the third line of this INPUT text somewhere else, select that line and run the Global Search macro, I get this regex : (?=[[=O=]])\X(?=[[=u=]])\X(?=[[=r=]])\X(?=[[= =]])\X(?=[[=f=]])\X(?=[[=r=]])\X(?=[[=i=]])\X(?=[[=e=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[=s=]])\X(?=[[= =]])\X(?=[[=Š=]])\X(?=[[=a=]])\X(?=[[=r=]])\X(?=[[=u=]])\X(?=[[=n=]])\X(?=[[=a=]])\X(?=[[=s=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Đ=]])\X(?=[[=o=]])\X(?=[[=r=]])\X(?=[[=đ=]])\X(?=[[=e=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Ø=]])\X(?=[[=r=]])\X(?=[[=j=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=P=]])\X(?=[[=a=]])\X(?=[[=w=]])\X(?=[[=e=]])\X(?=[[=l=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=S=]])\X(?=[[=t=]])\X(?=[[=e=]])\X(?=[[=f=]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=i=]])\X(?=[[=a=]])\X(?=[[=,=]])\X(?=[[= =]])\X(?=[[=Á=]])\X(?=[[=n=]])\X(?=[[=g=]])\X(?=[[=e=]])\X(?=[[=l=]])\X(?=[[= =]])\X(?=[[=a=]])\X(?=[[=n=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=U=]])\X(?=[[=ğ=]])\X(?=[[=u=]])\X(?=[[=r=]])\X(?=[[= =]])\X(?=[[=h=]])\X(?=[[=a=]])\X(?=[[=d=]])\X(?=[[= =]])\X(?=[[=a=]])\X(?=[[=l=]])\X(?=[[=r=]])\X(?=[[=e=]])\X(?=[[=a=]])\X(?=[[=d=]])\X(?=[[=y=]])\X(?=[[= =]])\X(?=[[=l=]])\X(?=[[=e=]])\X(?=[[=f=]])\X(?=[[=t=]])\X Finally, if you select the 1,079 characters of this regex and open the Find dialog with Ctrl + F, you can easily verify that it matches, successively, the four lines of the INPUT text. Whaooou ;-)) Note that I could have chosen the first, the second or the fourth line, either. The resulting regexes would have matched the four lines of the INPUT text, as well ! Best Regards, guy038

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

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

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

@Coises You’re welcome, and thank YOU for promptly creating the new version, and for your plugins in general to begin with! The new one lets me exit without incurring any dialog.

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

@Sylvester-Bullitt , Release Candidate is available. You probably want to test this version, and report any continued problems with the Open File feature ASAP.

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