@Coises said: …fail…in virtual machines I’m somewhat curious about this, because, well, isn’t the idea of a VM that it runs the same as a real machine? If it doesn’t, isn’t it a lot less useful? OK, sure, it doesn’t run strictly the same entirely, but I’d say running an app, e.g. N++, either under a VM or not should produce the same results for the user. I’ve run Notepad++ exclusively under a VM for 3+ years now, and have never noticed any behavior that was odd. I guess what I’m looking for is that you did something really “oddball” in your plugin, and that in general I have no reason to be concerned.

@J-Mark-Barfield , that was not a “regedit”, that was a normal command-line command all those two commands did was run an instance of notepad++.exe without RunAsAdmin privileges, even before you made the change to the executable compatibility settings it was completely unnecessary all you had to do was exit Notepad++ application completely (so it wasn’t running), then do the steps I explained to get notepad++.exe to not run as admin, and then the next time you ran Notepad++ (either using your shortcut or double clicking on the exe or running the exe from the command line normally or double clicking on a text file or right clicking and choosing Edit with Notepad++) would have run Notepad++ not as admin if you didn’t exit Notepad++ first, then the still running Notepad++ instance would still be running as Admin. Changing the exe properties while the exe is running doesn’t magically drop the running Notepad++ out of Admin mode. And thus your right click would not have worked, because the running Notepad++ was still in Admin mode. all you did by doing those extra commands was close the Notepad++ that was running as admin open a new instance that wasn’t running as admin change the exe properties so that it wouldn’t run as admin next time (I understand that you got it working, so you don’t really care at this point. But I don’t want future people to read this discussion, and come to the wrong conclusion that they need to do your extra steps. Those steps were completely unnecessary.)

@PeterJones Without the whale, it’s just Burns and Allen.

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.

@Passant-Delarue , Initial guess: turn off “. matches newline”, otherwise your .* will greedily match the whole file.

@PeterJones by reset itself i mean only the plugin and i mean it revert back to the state it was when i first installed it meaning no profiles, and everything else i changed also reset. simply a TOTAL reset of the plugin. That sounds like it’s not saving its config files correctly… and here is the debug info: … Admin mode: ON So this might be one thing: if you sometimes run as Admin and sometimes as normal user, config files can get their permissions messed up, which might be a culprit. In modern Notepad++, unless you are almost always editing files from the Program Files or Windows folders, there is no good reason to run As Admin consistently – as a normal run of Notepad++, if you try to save a protected file (files in Program Files, Windows, etc), Notepad++ will ask the OS, and the OS will prompt you with the elevated UAC permission to write the protected file. So unless you are saving a file to that location often enough that the UAC prompt every save becomes annoying, don’t run as Admin. Cloud Config: C:\Users\אפיק גלבוע\Documents\NppSettings Hmmm… there might be two things there, as well. First, I don’t know whether the NppFTP plugin was written with good support for Unicode characters in path names. So it might not be able to write its config to a directory like that. Second, I don’t know if NppFTP was properly written to make use of Cloud Config. If it’s using NPPM_GETPLUGINSCONFIGDIR, then it should be getting the right location, but if it’s incorrectly manually figuring out the plugin settings directory relative to AppData, it might not be computing the right path, so it might be trying to save its config in the wrong place (maybe even to a non-existent location) Look in C:\Users\אפיק גלבוע\Documents\NppSettings and see if there is an NppFTP subdirectory there. If not, then likely one of those two problems has occurred. If there is, then look at the permissions of that directory and the NppFTP.xml in it, to make sure that both your normal user and your elevated Admin have permission to write to it.

@Krzysztof-Blachnicki said: I deleted ExtSettings.ini (which was 0 byte) and… It works again. Maybe it’s n++ fault, but… For other plugins settings aren’t gone and when files are 0b they don’t cause glitchy behaviour. I’d bet it’s rather a problem with this particular plugin. If deleting the ExtSettings.ini caused the problem to go away, then I am confident it is the plugin, not Notepad++ itself, that is the culprit. The question is what now? Whom I can ask for reaction? Report the problem to @dinkumoil , the author of the plugin => https://sourceforge.net/projects/extsettings/support

@PeterJones said: You also mentioned “uninstalling the plugins and reinstalling them” – that sounds like you have both plugins installed at the same time. I highly doubt that it’s a good idea to have both Compare and ComparePlus installed on the same instance. Sorry, I only have Compare Plus installed now - so I tried uninstalling and re-installing it to see if it was fixed. Both are not installed. As far as I can tell, neither Compare nor ComparePlus has a “cancel” action. They have a “Clear Active Compare” action. Are you saying that you hit that “Clear Active Compare” button while it’s still working on making the comparison, to stop it in the middle? Or do you just mean that you are clearing the comparison once it’s done? I am hitting this cancel button to stop it in the middle of working; [image: 1786224004669-97162e74-5601-4918-b18e-1dfa20830fa5-image.jpeg] But with normal usage (telling it to compare, looking at the results, clearing the active compare), I have never gotten to the point that the plugin just hangs indefinitely. If you have a pair of files (with no private information) that you can get to cause the hang reliably, and can explain, in detail, the procedure that you use to cause the freeze, then I would recommend that you create an issue at the plugin’s GitHub repo so that you can let @pnedev know about the problem. I will do this - although I suspect it will not reproduce since these same files worked at first for me too. Thank you…

Search++ version 0.6.4 is available. It is expected to fix the bug reported here. Even though it seems most people never experience that bug, I still recommend upgrading at the next convenient time, so we will all be testing the same code. It’s always possible that I broke something else. I am still working on improving the multi-threading for find in files. I’m also trying to decide how best to mitigate a problem wherein Search++ fails to load when a particular Windows redistributable library has never been installed on the system. More updates should be coming before too much longer. All thoughts, suggestions, comments, criticisms, bug reports and raspberries are welcome, and thank you to everyone willing to give this jalopy a good work-out.

@PeterJones Okay, yes, there are several subdir in that folder that are links (issue #18248). Actually, the first subdir is a plain one and is displayed whereas the second one is a link and is not displayed while preventing the display of the remaining data. I’ll give the RC a try. Thanks again.