FWIW, plugins also look different in v8.4.9 when compared to v8.4.8. I guess this is also because v8.4.9 is a Windows Vista rather than a Windows XP executable now. Anyway, I think this is unlikely to cause any serious issues, so it’s probably fine.
@DomOBU ,
I can’t read French, but that’s also why I see things in French in the code, but I suspect you’re showing him what my Ad-Blocker is finding worth blocking. I mean, it could even just be the Google Tracking, that is being blocked for all I know. I only know that I like Ad-Block doing it’s job, period. :)
When a site insists I shutdown the Ad-Block, I close the site, instead. :)
@donho, @Bogdan-Voaidas, the only problem with Elastic Tabstops is this annoying dialog that hooks the NPPN_FILEBEFORECLOSE event when the given buffer has not been added (“regist[er]ed”) to the plugin’s private list of remembered files. The code never reads from or writes to session.xml, posing zero risk to a user’s unsaved files.
It’s more likely @Bogdan-Voaidas’s session file was moved / overwritten / corrupted by N++'s installer. Lesson learned: if you’re not backing up your personal config files before every upgrade, you’re rolling the dice.
Thanks for the Helpful Suggestions. I think I figured out why it’s doing this, but I don’t know how to fix it. The app is installed on my OS drive, which is an SSD, but it seems Notepad++ is waiting for my other drives, which are regular HDD to spin up before it launches.
For the bug report please do it in “General Discussion” or “Help wanted”.
If it is a REAL bug report, report it HERE.
If you want to discuss it first before filing an actual report, then yes, “General Discussion” or “Help wanted” is fine.
It is not necessary to open an issue. Using SysInternals’ ProcMon I was able to figure out that Notepad++ reopens a file when its character encoding is changed. So, the issue I was talking about should be resolved automatically when already existing issue Reloading a file will mark all lines as changed in change history bar gets resolved.
I can reproduce it. The issue is kind of reminder (assigned to me) to put me on the track when I’ve time to work on it.
You can add it yourself into in your stylers.xml, or just remove it, a new stylers.xml will be copied from stylers.model.xml
The Change History margin’s color is difficult to manage.
It could use the Line Number margin’s color style ID 33 (Scintilla default behaviour) and users cannot customize its color at all.
Or we provide customization (it’s the current option) to disassociate it from style ID 33, but there will be such glitch while switching among the themes.
We have to choose one or another - the perfect world doesn’t exist.
