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

@gstavi said: (You replied to my comment, but I’m not sure this was directed to me. In case it was…) Professionals who search 100,000s of files with Notepad++ are not professionals. Professionals, when they reach that scale (and long before), use command line tools. Then they open the found files in an editor. Possibly Notepad++. I don’t really care who is or isn’t a “professional.” I started working on Search++ mostly to experiment with some user interface changes to provide more flexibility, while also wanting to expose the enhancements (formulas, more complete Unicode support) I built into the search in Columns++ in a more general-purpose framework. It’s all way too much to propose as a change to the base program. I’m hoping that eventually (there is much work yet to be done) it can be a practical alternative to Notepad++’s built in search for people who like the user interface changes. So, along that line, my current phase of development is working on Find in Files. Because I don’t rely on Scintilla’s interface for regex searching (I use a separate copy of Boost::regex with custom iterators directly against the Scintilla buffer), I can skip Scintilla entirely when reading files from a folder. The main performance bottleneck of search in files was that every file was fully loaded into Notepad++, then its encoding was guessed. Probably with extra overhead as if this file is about to be displayed. Then its contents were scanned for matches as if it was regular search. Simple, elegant and SLOWWWW. That part I skip, except that I still have to work out the encoding. Right now I handle all three forms of byte order mark, and in the absence of a BOM I differentiate valid UTF-8 (including pure ASCII) from anything else — anything else being processed using the system default code page encoding. I don’t yet handle files with an internal character set declaration (like HTML or XML), UTF-16 without a byte order mark, or legacy code pages other than the system default. The #1 required performance optimization is to have “search files as utf-8” feature which is basically grep. Assume all files are utf-8 (or ascii or binary). Scan them with efficient buffer by buffer linear algorithm without loading the entire file to Notepad++. But this is a different new feature, not optimization of current search which is still needed by people who (for some reason) use multiple encodings. I have part of this optimization (no Scintilla and no encoding conversion, just use the correct iterator for the detected encoding), but I still read the entire file into memory, because processing the full possible range of Boost::regex regular expressions without the entire text present would be very challenging (if not impossible). I gather grep is normally limited to line-by-line processing; that wouldn’t fit with what people expect from regular expressions in the context of Notepad++. It has occurred to me that a future (probably far future) enhancement to my plugin might be to offer the RE2 engine as an alternative. Since it doesn’t backtrack, processing gigantic files without needing to read too much data into memory at once would be possible. The #2 performance optimization is probably asynchronous I/O before multithreading. Maybe with modern NVME drives this is less true than it used to be with spinning disks. Still true for search over network share. I’m still experimenting. My last public version (Search++ 0.6.3.1) uses memory-mapped I/O for files that are not remote, but further testing has shown me that has little-to-no gain over just sequentially reading the files into a buffer for either my NVMe SSD or an internal hard drive. The next thing I plan to try is “decoupling” reading and searching. Right now each thread reads and then searches; there might be some gain from separating those (a reading pool pushing to a queue from which a searching pool pulls), though my experience over the past two or three weeks has shown me I can spend a great deal of time pursuing a theoretically better alternative only to have it make no real-world difference at all. So far the most stubborn problem I’m up against is figuring out how many I/O operations to submit at once. An SSD definitely benefits from letting all cores hit it with requests at once. A USB thumb drive suffers from that, and can actually perform worse than single-threaded… except when the files are cached from just having been read before, in which case they act like an SSD. For a remote share, the optimal number of simultaneous requests probably depends on the current state of the network — something I have no real way to model and test. If you happen to know of a practical, real-world implementation of Windows code that determines at run time how many simultaneous read operations to issue against whatever is hosting a given folder for maximum throughput, please tell me about it. Multithreading is 3rd priority. It is extremely unlikely with original algorithm and rather easy for search as utf-8. I’ve managed to get around 13 times the performance of Notepad++ native search on an SSD in a system with an i-9 9900K (16 threads). Some of that is probably due to avoiding the use of Scintilla, and some (I think most) to multithreading. I am definitely not a “professional” when it comes to having a clue how to measure performance properly, though, so not too much should be made of any of it. But again, opinions of people who can’t mix and match the right tool for the job and insist that every tool should adapt itself to their selfish needs should not have much weight. Agreed about the “insist” part. It’s almost always more productive to learn about what tools exist than to whine about how the one with which you are familiar doesn’t work the way you wish it did. Yet users’ complaints are how those of us who develop software learn about what might be useful. That doesn’t mean we always can or should give people what they think they want — they know what impedes or annoys them, not the best way to make it better — but it tells us where existing tools fall short. It’s up to us to design ways to fill in the gaps, though not always the way a non-programmer might have imagined it.

Hello, @troglo37 and All, OK. So let’s start off slow ! First of all, I’d like to check with you to make sure we’re on the same page about our goal : If we begin with this text : Our friends Sarunas, Dorde, Orjan, Pawel, Stefania, Angel and Ugur had already left Our friends Šarūnas, Đorđe, Ørjan, Paweł, Ștefania, Ángel and Uğur had already left Our friends Šarūnas, Đorđe, Ørjan, Paweł, Ștefania, Ángel and Uğur had already left As you can notice these lines are quite similar and differ only because of some accents in the first names : The first line does not contain any accent The second line contains some characters with an accent. Here are their Unicode values : Š = 0160 ū = 016B Đ = 0110 đ = 0111 Ø = 00D8 ł = 0142 Ș = 0218 Á = 00C1 ğ = 011F The third line contains — when it was possible to find an equivalent — a classical ASCII letter immediately followed with a combining diacritical mark — an accent — thus two characters for one glyph. However, the letters Đ, đ, Ø and ł, without equivalent, are single characters only, like above ! S + 030C = Š u + 0304 = ū Đ = 0110 đ = 0111 Ø = 00D8 ł = 0142 S + 0326 = Ș A + 0301 = Á g + 0306 = ğ Now, I assume you’d be interested in finding any of these three syntaxes — or others like them — at the same time, in your file(s), right ? @troglo37, just tell me if this is your goal ? See you later ! Best Regards, guy038

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

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

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

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

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

1.2.1 Syntax highlighting PowerShell Added document comment syntax highlighting [image: 1785067576590-doxygen1.png] [image: 1785067576858-doxygen2.png] Added injected code syntax highligting (inside @''@ or @""@). [image: 1785067606620-member1-resized.png] [image: 1785067607237-member2.png] Types ([int], [string], …) got smooth colors Updated keywords and built-in variables (PSObject, $this, …) AutoHotkey Improved JsDoc (document comments) highlighting [image: 1785067628669-doxygen.png] [image: 1785067628705-doxygen2.png] Improved @Ahk2Exe-Keep comments (shows code that will be executed only if it was compiled via Ahk2Exe) [image: 1785067642264-keep1.png] [image: 1785067642424-keep2.png] Improved ahk2exe directives colors (displays all directives). Type any directive, like console or keep, and auto-completion will insert code snippet with this directive Fixed Issues with paths syntax highlighting (relative and absolute). [image: 1785067694213-paths.png] Variables interpolation inside quotes and paths [image: 1785067703084-interpolation1.png] Unexpected orange background, light theme, wrong font and colors on some systems. Removed unavailable/empty themes. Missing return types in popup docs and functions hints for some AutoHotkey built-in functions.

@guy038 has given a good example here also: https://community.notepad-plus-plus.org/topic/27611/is-there-a-way-to-find-both-alphabets-with-and-without-accents-at-the-same-time-when-searching

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