AutoCodepage plugin and the new change history issue

datatraveller1

I have been using the AutoCodepage plugin for a few days. It works great for my needs, e.g. I can specify to open .bat files with code page OEM 850 now. However, every time when I open a file with this plugin, the green bar (indicating saving) of the new change history is shown for the whole file.

Any ideas how I can open files without the green bar? I assume the plugin reloads the file from disk. Is this is an issue which will be fixed with the next Notepad++ version or a task for the plugin developper?

PeterJones

@datatraveller1 ,

My guess is it’s in the plugin itself.

With raw Notepad++, the implications of the green-bar showing up everywhere are that it changed every line of the file, then saved; or that you used the “reload from disk” option, which also sets everything to green.

So if any of AutoCodepage’s “tricks” for changing the codepage make Notepad++ think that every line has been changed+saved (or reloaded from disk), then that’s the procedure that’s telling Notepad++/Scintilla to highlight all the lines. Since you specifically say you think that the plugin reloads the file from disk, that would be sufficient.

datatraveller1

@PeterJones Thank you very much.
I’m not sure (can’t remember exactly): Is it a bug that File > Reload From Disk will turn it all green or not a bug?

dinkumoil

@datatraveller1 , @PeterJones and all

FYI: My AutoCodepage plugin does not reload a file whose encoding should be changed. Instead it emulates a mouse click on the menu entry related with the desired character encoding by firing a NPPM_MENUCOMMAND Notepad++ message.

The green change history bar is created by the Scintilla editing component because of the actions Notepad++ performs when handling this message. So, I can’t do anything to avoid that green bar is displayed.

PeterJones

@dinkumoil ,

firing a NPPM_MENUCOMMAND Notepad++ message.

I confirmed, when I send NPPM_MENUCOMMAND with an argument of IDM_FORMAT_DOS_850, it properly changes the file to OEM 850, but it does change the Change History from empty to all-green. Or, if I start from a normal unedited (non-green) file and do Encoding > Character Sets > Western > OEM 850, it also turns the whole file green. Sorry for the mis-information (I didn’t have a chance yesterday to experiment with it, so it was just a guess based on the description, and not knowing how your plugin did things).

At this point, @datatraveller1 , I would recommend you follow the procedure in the Bug Report / Feature Request FAQ to create an official request. Explain that the circumstances are just using the Encoding menu to change the character set will cause the Change History to mark the whole document as green (saved-after-edit), whereas the expected behavior is that changing the character set should not affect the Change History at all.

–
update: I now see this is the main topic of conversation in the 8.4.7 RC topic, so you probably don’t need to create a feature request.

datatraveller1

Hi @PeterJones,
Thank you very much for your comments;
Hi @dinkumoil,
Thank you very much for clarifying and the great plugin!