Hello, @coises, Sorry, I haven’t commented on your latest version yet. In the meantime, I replied to @Vitalii-dovgan regarding his own implementation of the Find in Files feature. During that testing, I also included the Search++ plugin ( v0.7 ) and the MultiReplace plugin. So I invite you to take a look at it : https://community.notepad-plus-plus.org/post/106389 As for your latest version, I won’t be able to review it thoroughly until tomorrow evening. So, I’ll probaly get back to you on Saturday instead ! BR guy038

@guy038 said: @thomas-knoefel, I sure that you’ll correct this bug, very soon !! Yeah, maybe sooner than expected! Here is the fixed version of MultiReplace. Feel free to test the “Find in Files” performance and compare it with the other searches: Here is the fixed version

@donho Typo: “7 Fix Netork Path Warning dialog usability problem.” --> Network

@PeterJones said: I think that progress bar for FiF was possible because it’s possible to background a search-through-disk-file action. I know that a single-file search cannot currently have the progress dialog because the underlying search library doesn’t allow you to hook in a process-tracker. The find-in-all-open wouldn’t be able to track inside an individual file because of that limitation, but it might be able to check for cancel between files. Not quite. What’s missing is the possibility — no matter whether it’s from an open document or a file on disk¹ — to monitor progress during a single step of the search. Searching for all occurrences of something is implemented simply by repeatedly searching for the next occurrence of it. You can build a progress bar based on each step of the search. (I do that in Columns++ and Search++, and I believe Notepad++ does it for Find/Replace in Files.) The problem happens when a single search, usually one that never finds a match, takes a long time to complete. There is no straightforward² way to monitor its progress. ¹ Notepad++ implements searching files on disk almost the same as searching open documents: it just loads them into an invisible Scintilla control instead of one of the two visible views. For that matter, I believe documents that are not on a foreground tab must also be loaded into an invisible Scintilla control, but in that case the file is already loaded into a Scintilla document, so attaching that to a Scintilla control is a fast and simple operation for the base program. Plugins can’t do it easily because Notepad++ doesn’t expose the document handles for buffers that aren’t active to plugins (and Don has said that he won’t do that). I say “easily” because it is possible for a plugin to maintain a map of buffer IDs and document handles by carefully monitoring when buffers are activated, opened and closed. (I do it in Columns++ to try to maintain the layout tables for elastic tabstops. Since the change that Replace All in All Open Documents now turns off individual change notifications and just sends a notification that “something changed (none of your business what is was),” that code is mostly obsolete, but I haven’t removed it, if for no other reason, to maintain compatibility with older versions of Notepad++.) ² It’s not impossible. It would require writing a direct search routine rather than relying on Scintilla’s API, and for regular expressions one would either have to modify/fork Boost.regex or do some fancy shenanigans with the iterator class that scans the document.

@guy038 , I have also noticed that, recently, the username filter in the advanced search page doesn’t populate usernames. I had thought it might have just been me. I know that @barisusakli from NodeBB occasionally logs in, and they recently updated the forum software for us… maybe that version had a bug, because the admin panel says there’s another version available since they last updated us. Until then, once you make your search, you can edit the URL to set &by=PeterJones to search for my posts (right now, the URL probably has &by= with no value). It’s not as convenient as the drop-down, but it is a workaround.

@PeterJones said: So I have no clue why GitHub isn’t letting you type, as shown in your video. I recently realized what the problem is: browsers on Windows 7 cannot work well on the github.com website I apologize for the mistakes, lately I can hardly see at all. Cataracts have been detected in both eyes, and it is unknown when the turn for surgery will come.

@Vitalii-Dovgan , I don’t think the Plugins Admin will be able to do all of that on its own. The DLL needs to be at the top level of the zipfile. What you could do is to have your plugin intialization look for the autoCompletion and userDefineLangs files in the appropriate locations (use NPPM_GETNPPSETTINGSDIRPATH to make sure you put the UDL in the right per-user place, regardless of doLocalConf, -settingsDir, CloudDirectory, or normal AppData; autoCompletion always goes relative to NPPM_GETNPPDIRECTORY – and for any that are missing, copy from ...\plugins\SmartMath\ subfolder(s) into the right destinations. A possible zipfile structure could be: SmartMath.dll doc\ SmartMath.md autoCompletion\ SmartMath.xml userDefineLangs\ SmartMath.udl.xml SmartMath_Dark.udl.xml That would all get placed in ...\plugins\SmartMath\ Because autoCompletion definitions are in the program directory hierarchy, there may be a permission issue, so you’d have to request elevated permission to do that copy; examples of how I did that can be found in my ConfigUpdater plugin. (The plugin itself is not so useful, since I moved that feature to N++ itself, but some of the code is still useful reference.)

@ChotaFallen , Under default Monokai, I cannot replicate: [image: 1790262087450-9491595a-6d67-4abf-8758-f5ed5da6beb3-image.jpeg] However, if I change the Default Style > Background for Monokai (to a green similar to your second screenshot), I can see it: [image: 1790262414327-b8f97a3a-d5b4-43cd-b0f3-a1c35e66c366-image.jpeg] It’s because Monokai (and most themes) hardcodes every background color for every style, rather than using “inherit”. Here’s an example using the default style: [image: 1790262562644-9ba07e02-fb1d-4d2f-a580-d6cb2d7d5924-image.jpeg] The theme color choices aren’t always perfect, and not everyone is going to agree with color choices made. As such, you can customize to what you want. If you want most of the backgrounds for your theme to inherit from the “default background” rather than being hardcoded, you can go through and right click the background color for any that are the default. (Or, as a footnote, I will also explain a process that you can edit the XML for your customized Monokai, to automatically change anything that has a background that matches the monokai default background to inherit from default background, so that you can do it in a lot less time.) What I need is a better highlighed line I am working in, its black on dark that has nothing to do with highlight. … If I try to change it via Style congiruator the line will be solid in the color I choode doesnt matter for fore or background. Which “highlight” do you mean? And I am not sure what you aren’t liking about it when you change it. Current line highlight: default Monokai: [image: 1790262875579-db922444-92f4-4df3-91f4-9865727004fd-image.jpeg] set it to something else: [image: 1790262905945-fca66fe1-82d2-47cd-92cb-8c1ca0e6bc54-image.jpeg] it does exactly what I expect: it changes the current line background color 0x3E3D32 to something based on the color I selected. Selected text colour: default: [image: 1790263082002-6cf5b4c1-7b2e-47bc-8b20-47ad2ea1884a-image.jpeg] modified: [image: 1790263104839-6318a4e3-6d6a-4583-b949-855a439f304c-image.jpeg] again, it does what I expect Smart Highlighting: default: [image: 1790263153651-1107e88c-b40c-4622-b0e9-d2676004c323-image.jpeg] changed to cyan: [image: 1790263182686-3ba38b0a-1f92-4d9d-ba94-b36ef4d0c6f3-image.jpeg] this one, it’s actually combing the selected color with the normal background color, so it’s not exactly the same color you chose; but again, that’s not unique to Monokai Find Mark Style: used when you use Find > Mark dialog [image: 1790263284015-0e9c9f44-f393-44ae-b29a-386e362939bd-image.jpeg] Mark Style #: used when you use Search > Style … Token options: [image: 1790263340517-131aa3df-93bd-4977-9bd9-3143c4a7fbcb-image.jpeg] There are a few other, less likely, choices that you might mean by highlight. But rather than showing that I think it does what’s expected, it would be better if you were more specific about what you were doing, and what you don’t like, and what you would like. Footnote: Make Monokai backgrounds inherit quickly I assume you have a copy of Monokai.xml in %AppData%\Notepad++\themes\ . Exit all copies of Notepad++ Copy Monokai.xml to Monokai_custom.xml Edit Monokai_custom.xml with Notepad++ Confirm that <WidgetStyle name="Default Style" has bgColor="272822" – if not, manually edit it to use that Search > Replace, set Search Mode = Regular Expression FIND = (?-s)bgColor="272822".*\KcolorStyle="(?:(2)|(3))" REPLACE = colorStyle="(?{1}0)(?{2}1)" REPLACE ALL FIND = (?-s)(bgColor="272822"(?:(?!colorStyle).))*\h*/> REPLACE = colorStyle="${1} colorStyle="1" /> REPLACE ALL On the “Default Style” line again, delete colorStyle="1" Save the file Exit Notepad++ and re-launch it Settings > Style Configurator > Select Theme = Monokai_custom Now if you change Monokai_custom’s default background color, it should propagate to all the other styles (both normal text and each language), so it really changes the background throughout.

@Bondige-Ramesh , I am sorry you are having difficulty. Assuming you mean “Notepad++”, not “Notepad” (they are two different applications – Notepad++ is what’s discussed in this forum; Microsoft’s notepad.exe is a separate product, and is not the focus of this forum) please share your ?-menu’s Debug Info, so we know what version of Notepad++ you are using, and get some useful information to help us replicate and diagnose your problem please be more specific than saying “suddenly loaded as empty” over and over. If it’s just a matter of you had a file, then accidentally deleted its contents, there is not much we can do to help you: we have a FAQ about backups, which gives a couple places to look, depending on what your Notepad++ backup settings are. But the chances are, now that the file loads empty, you have likely lost your data.

I said: In case anyone else is interested, you can try previewing plain-text wireloom files with this development build of Preview HTML. This feature has now been merged, with additional support for offline Markdown previews that will render wireloom code blocks: [image: 1790348955006-wireloomx898.gif] All rendering is done by client-side JavaScript modules, so MS Edge is still required. @Keith-Collyer said: What would be really good would be if the developers of these re-merged their plugins! Don’t look now, but no fewer than three new Markdown plugins have appeared in the past two weeks — and they all depend on the WebView2 runtime (i.e. Edge).

I am seeing an issue that I’m not certain it is the installer of Notepad++ 8.9.8 itself or if Microsoft has inadvertently caused this… Using Microsoft’s Enterprise App Catalog to install 8.9.8 on top of an existing installation of 8.9.6.4 seems to result in the registry information being updated to say 8.9.8 but when you check C:\Program Files\Notepad++\notepad++.exe it is still 8.9.6.4. This was horrifying, as it’s the perfect way to maintain a vulnerable copy of the app on Enterprise systems. It could go completely unknown because, at least on ours, MDM systems seem to inventory based on what the registry says and not what’s on the actual disk. Server OS endpoints updated using the traditional SCCM method appear to update correctly. So, this adds weight to the issue being Microsoft’s Enterprise App Catalog implementation. It is almost as though they are updating the registry on behalf of Notepad++, ignoring the true status of the app.

@donho There seems to be another one: notepad-plus-plus . app I reported this too. GH issue: NPP brand impersonation website serving malware #18398