@guy038 said: Now, I did a test, searching in all files of my D: USB key, with : The native N++ Find in Files dialog The Search++ Search in Files dialog The MultiReplace Find All in Files command To be sure to process fair tests, I unplung my USB key, re-start my laptop completely, replug my USB key and starts a new N++ session, before running these three Find in Files operations, in turn ! I searched for the Fi string, with the Match case and the Regular expression options checked. I got : 27,112 matches in 833 files of 1,761 searched for the N++ Search Results panel, in 1m 37s 27,112 matches in 833 files of 1,761 files for the Search++ Search++ Results, in 2m 21s 27,087 hits in 835 file(s) for the MultiReplace Search results panel, in 1m 36s I have been struggling with how to optimize the multithreading of my search for over a month now. Among other things, I’ve found that most everything I thought I was measuring wasn’t what I was actually measuring. One surprise I only recently discovered was that even if I eject and unplug a thumb drive and then plug it in again. there is still a “first time today” cost in the time it takes to read it. Windows is persisting something and it is able to identify the same drive, even though it’s been unplugged. I don’t know the exact time, but Windows on my machine keeps it for more than an hour and less than 24 hours. Running a particular test the first time I plugged in a particular USB drive I have, it took 8 minutes and 26 seconds. After ejecting the drive, unplugging it, waiting a moment, plugging it back in and running the exact same test, it took 20 seconds. This drive appears to take whatever it is that Windows does once a day (?) exceptionally hard. Most drives don’t show anything so obvious. This is the only drive I have tested so far that uses FAT, so that could have something to do with it. I haven’t yet tested whether rebooting is enough to reset the “once a day” penalty, or if it persists in something that isn’t lost in a reboot. It may have something to do with antivirus, though I haven’t yet proven any such thing. So I’m wondering, if you happen to remember, whether you tested in the order you listed, or whether you happened to test Search++ first? In any case, after weeks of running in circles, I think I will soon give up the fight to optimize performance and see what else needs work.

@Afik-Gilboa said: both of them have the “run as administrator” unchecked. so any ideas why it keeps opening in admin mode? apparently everything running as administrator here, not sure why but it’s everything… I recognize the symptoms - you probably have turned off the Windows UAC completely somehow and at the same time the account, you are logged in, has the administrator rights (then everything launched will have the admin rights as default). Check your Registry for EnableLUA REG_DWORD 0x00000000 in: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] (click on Windows Start, start typing “Reg” there, click on the Registry Editor (System) app offered and navigate there to the hive path above) If there is that 0x00000000 (OFF), change it do 0x00000001 (ON) and restart your PC.

@PeterJones, many thanks to Your reply. This workaround works perfectly. I searched for this workaround (because I expected that anyone wouls have the same needs) but wasn’t successful - searching for a solution to a problem can be a frustrating experience if you don’t use the right search term(s) — which, of course, you don’t know yet at that stage…

@saintleningrad-prog said: Select text, or place the cursor inside a ^^…^^ tag, press Ctrl+Shift+E Just a head’s up: that’s the same default key combination that decodes HTML entities when HTML Tag is installed. Since plugin commands are mapped in alphabetical order, and the most recent mapping prevails, having both installed will silently block the EncTag’s plugin shortcut from functioning: [image: 1787355567929-enctags-v020-shortcut-conflict.png] One more thing: the text you are passing to the About message box (here) contains the literal Unicode character U+2013: EN DASH. Since the Unicode literal is inside a character string, the compiler interprets everything between "..." as if it were encoded in the operating system’s default, single-byte code page (usually Windows-1252 on English- or European-language PCs). When shown, the emdash becomes the string of nonsensical bytes \xe2\x80\x94: [image: 1787355726977-enctags-v020-mojibake.png] You just need to escape the Unicode literal, i.e., "Ctrl+Shift+E \u2013 ..."

@dcog989 Thanks for this - if you have any tweaks or updates you’ve made since this comment, let me know!

@Coises said: I expect that Version 0.6.5 will fix this. Noted, thanks again, and I’ll let him know — although he actually doesn’t typically use regex for his own purposes.

Since it’s essentially working at this point, I’ve renamed the Topic to “BETA” @mpheath , I have updated the README at https://github.com/pryrt/NppPlugin-HiddenLexers to enumerate available options I think I’ll be patient, and give the beta test a while longer, so won’t try to rush to release it before N++ v8.9.8’s PluginsAdmin list is finalized.

1.2.2 Syntax highlighting PowerShell Improved absolute, relative, quoted and unquoted paths colors [image: 1785402977913-paths.png] Improved variables interpolation colors [image: 1785402952228-interpolation.png] [image: 1785402954396-interpolation4.png] Added colors for expressions $(..), ${..} Added registry hives colors (HKLM, HKEY_LOCAL_MACHINE, …) Fixed syntax highlighting Fixed variables colors inside paths and quotes Fixed excessive colors of variables, keywords, and functions enclosed in quotes Fixed unexpected sc.. and vk.. colors in AutoHotkey code Disabled colors for variables inside single quotes ' ' (because single quotes prevents var. interpolation)

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

@rdipardo thank you for pointing that out. I will check and do the needful.

Thank you again for your help.

@chtaylo3 , You only need to post in the “Support for Plugins Admin & NppPluginList” topic if there’s a feature or bug with the Plugins Admin and the list DLL itself. If there are issues with your PR to add it to NppPluginList, those will be discussed in the PR itself – and it looks like yours has been accepted already. If you want to just announce your new plugin, you can just create a new Topic in the Plugin Category to tell us about it. Hence, I am moving your post to its own Topic. And congrats on creating a lexer plugin!

NppExec v0.8.12.1 has been released! Glory to Ukraine! Glory to the heroes! improved: now WarningAnalyzer automatically removes “” around a file path/name fixed: the Console Output Filters dialog did not clear WarningAnalyzer’s cache improved: now Highlight’s [I], [B], [U] have Italic, Bold and Underline style Get it here: https://github.com/d0vgan/nppexec/releases/tag/NppExec_v08121

@Michael-Vincent Thanks for the feedback ;) fixed with : https://github.com/gcyrillus/nppGitClone/releases/tag/V1.0.1

@Michael-Vincent and anyone reading :) Besides the jokes, i’d like some real feedback about the plugin, the code and mainly about the fact that gemini assisted me … Be critical without trolling, do not be afraid to point out all of the funny code, nonsense and incoherence that a light IA can bring within your code unless there is some goods in it . Good jokes are also welcome ;)