@mpheath Okay, I’ll check it out. Thanks.

It looks like @LucaSorvillo took me up on the recommendation: Created new Issue #18496 , so there’s an “open issue” to PR against Created PR#18497 to implement it as a sub-option of the Tab Bar > Behavior > Vertical option

@shocked-gamer , @peterjones is right. I only use Firefox myselff, and it’s in dark mode right now…however, you have to be signed in. For instance, I always sign out. When I do, the light theme comes back on, until I again, sign in. I believe it’s linked into your account, and it apparently works, or it wouldn’t go dark after I’ve signed in.

@Karen3D , That sounds like a permissions issue… but you aren’t running in Admin mode, so usually there isn’t such a thing. What are the results of the following experiment? Exit Notepad++ delete %AppData%\Notepad++\session.xml Run Notepad++ Open 3 files Exit Notepad++ Look at %AppData%\Notepad++ Is there session.xml ? If you open it (with notepad.exe or some other editor), what are its contents What permissions does it have? Windows Right-Click properties, Security tab, click on your username, it should have all the normal permissions checkmarked, like: [image: 1791574173538-9a809e1e-abff-40ed-aa52-7df27aa9f984-image.jpeg] If it’s there, and your three files are listed, then when you next run Notepad++, it should load those files. If it does, great, problem solved. If it doesn’t, then as long as it’s not a security issue (ie, unimportant filenames/paths without secrets in the path), it would be great if you could share the contents of the session.xml, as well as confirming that your Debug Info is identical to what you shared above, and paste screenshot of your Settings > Preferences > Backup

Search++ version 0.7.2 is available: Correct failure to find a zero-length match at the end of a file, selection or span of marked text when the previous match included last character of the file, selection or span of marked text. Condense Tools | Synchronize sub-menu. Implement Tools | Expand visible configure tool window. Keep use of hidden lines in Search++ (almost) consistent with the way Notepad++ handles hidden lines and fold points. Hidden lines now show unhide margin markers. Hidden lines stay hidden after leaving and returning to a tab (except for the first and last line, which Search++ Hide all lines and implicit hide before Show commands hide, but Notepad++ native actions never do). Stepwise searches, Select and Show commands, and clicking on a match in the results window now properly unfold collapsed sections when necessary to show a match. Comments, criticisms, suggestions, bug reports and other observations are most welcome! A little over a month ago I claimed: I use Scintilla’s hidden lines feature directly. Notepad++ also uses that feature, but it doesn’t provide a way for plugins to use it through Notepad++, and it keeps internal status information that assumes only it is using hidden lines. There appears to be no way to make Notepad++ synchronize its own idea of which lines it thinks are hidden with the actual state of Scintilla. Various bizarre things happen because of this. I was wrong about that. I didn’t read the Notepad++ code carefully enough and jumped to an incorrect conclusion. I fixed a couple bugs in this release, but the main change in 0.7.2 is making hidden lines, particularly as used by the Show command, work consistently with the way Notepad++ uses them. Aside from any errors in my implementation, the one known, intentional discrepancy is that when Search++ hides all lines that includes the first and last line of the document. Notepad++ refuses to hide those. Under some circumstances, such as switching from a tab in which you’ve run a Show command to another tab and then switching back, Notepad++ will show the first and last line; at present I don’t attempt to override that. Versions of Search++ prior to 0.7.2 failed to coordinate hidden lines properly with Notepad++ at all, so switching tabs would lose all information about what Search++ had hidden. I also added more flexibility to Tools | Expand visible, which is primarily for showing context around matches after a Show command. You can now open a small tool window that lets you choose how many lines to show before and after in one step, and whether to show them around all visible blocks or only the block(s) containing the cursor or selection. This is a new feature, so observations about its clarity and usability are most welcome. It is described here in the help. One known problem is that when double-clicking a match or other position in the Search++ results window opens a new tab (that is, the file wasn’t open in Notepad++ already), the document fails to scroll to show the match or position. Double-clicking a second time (now that the document is open) scrolls correctly. I think I understand why this is happening, but I have not yet devised a way to make it work as expected.

Echoing what @Lycan-Thrope said — it is worth trying the GDI workaround before settling on the old Compare plugin, because that older plugin is no longer maintained and can develop incompatibilities with newer Notepad++ releases. To try the fix suggested earlier in this thread: go to Settings > Preferences > MISC., find the rendering-mode drop-down (DirectWrite is the default), switch it to GDI, then fully restart Notepad++ and run the same comparison again. The crash appears tied to how ComparePlus draws its difference highlighting under DirectWrite, so GDI sidesteps it. Two extra things worth checking if it still crashes: Test with all other plugins removed, in case something else interacts with it (XML Tools was installed alongside ComparePlus in the original report here). Check whether file size or shape matters — try a small pair of files first, then the large XML files, to see whether size plays a role. If you get a chance, please report back whether the GDI switch helped. The plugin author said a reworked ComparePlus is on the way that should fix the DirectWrite problem, so a data point either way helps everyone following this thread.