Notepad++ 7.7 breaking change of SCNotification definition in x64 build

Predelnik

I don’t know if many plugins make use of SCNotification struct but since updating Scintilla to 4.14 type of its second field called position was changed from int to Sci_Position which is basically ptrdiff_t. Thus if you use it by old definition every field except the first one will unfortunately be shifted.

So basically each plugin using SCNotification should update its scintilla.h to work correctly with Notepad++ 7.7

pnedev

Hi all,

Good point @Predelnik .

The question is shall the affected plugins be updated in the PluginAdmin’s list?
The answer is probably yes but this means that those plugins will not work then in Notepad++ versions prior 7.7 as the nppPluginList is not per Notepad++ version.

Perhaps there should be minimum and maximum required Notepad++ API for each plugin in the nppPluginList json file (those might not be mandatory but the idea is to be unable to install plugins from PluginAdmin that are not compatible or at least the user to be warned about that. Or why not to be pointed to the right plugin version for the corresponding Notepad++ version?).

BR

Meta Chuh

@pnedev

The answer is probably yes but this means that those plugins will not work then in Notepad++ versions prior 7.7 as the nppPluginList is not per Notepad++ version.

no, nppPluginList currently is per notepad++ version.

the older versions will only present you with the plugin versions that existed at that specific notepad++ version’s release date.
so it’s safe to update the newer versions.
older notepad++ will always download older plugins, this will also stay the same, if notepad++ would get a live nppPluginList one day, as the older npp releases will not use such live lists.

best regards.

dinkumoil

@Predelnik , @pnedev

AFAICS there are even more members of the SCNotification struct which have been changed from int to Sci_Position, namely

length
linesAdded
line
annotationLinesAdded

See >>> here <<<.

PeterJones

@Meta-Chuh said:

older notepad++ will always download older plugins, this will also stay the same, if notepad++ would get a live nppPluginList one day, as the older npp releases will not use such live lists.

It will stay the same for ones we call “older” now (like 7.6.6, or even v7.7, since it still uses the fixed list)

Assume for the moment that “live” nppPluginList is released with v7.8. When v7.9 then releases sometime later and nppPluginsList is then updated as plugins add SuperNiftyFeature79 to their plugins, there may be some plugins that are compatible with v7.9 that are not compatible with v7.8… but since v7.8 uses the live nppPluginList, it will try to download plugins from the most-recent live-nppPluginList. Implementing @pndev’s suggestion of compatibility ranges in the nppPluginList now, before live-nppPluginList is released, will help future-proof the live-nppPluginList system. Waiting until users start complaining (“I have Notepad++ v7.8, and suddenly it’s downloading plugins that claim they aren’t compatible with v7.8”) to fix it might be harder than getting it implemented now.

dinkumoil

@PeterJones said:

Waiting until users start complaining (“I have Notepad++ v7.8, and suddenly it’s downloading plugins that claim they aren’t compatible with v7.8”) to fix it might be harder than getting it implemented now.

Yeah, do it right at the right time and not when foreseeable issues arise.

PeterJones

@PeterJones said:

Implementing @pndev’s suggestion

/me notices he misspelled @pnedev’s user name. Sorry. (Username links are one of the things that doesn’t render in the PREVIEW window when editing a post, so it’s harder to notice. :-( )

Predelnik

@dinkumoil said:

AFAICS there are even more members of the SCNotification struct which have been changed from int to Sci_Position, namely

Good point! But change of the size of the second argument is already enough to make access by previous definition incorrect in almost all of the cases unfortunately.

pnedev

Hi @Meta-Chuh ,

I didn’t know that, thanks.

Does this mean that if I have Notepad++ v 7.6.6 and never change it I won’t get any plugin updates or newly released plugins ever?

BR

Meta Chuh

@pnedev

yes, correct.

even if a newer plugin version has been submitted to the current pluginlist, 7.6.6 will only use the one it was shipped with, inside nppPluginList.dll.

same for all older versions since 7.6.
it’s a cool thing for testing though, as i have every portable npp version, and i can download exactly the old versions of a plugin available at that time (as long as the author doesn’t remove the older release downloads from his repo)

best regards.

dinkumoil

@all

I’ve filed an issue, see >>> here <<<.

pnedev

@Meta-Chuh ,

OK, thanks.

Its cool for testing and support but not quite flexible for the user.
If you want your plugins updated (or get newly released plugins) via PluginsAdmin you are forced to update Notepad++ itself.

pnedev

@dinkumoil ,

I have added this suggestion. I think it is the better approach.

Alan Kilborn

It didn’t seem quite right to mention this in the github issue, but this forum is more tolerant if you get off topic…

Thinking about these proposed Plugin attributes and the recent changes (and then change-back) in core Notepad++ security/authentication, what assurances do we have that plugins are coming across from untampered-with files?

gstavi

Sci_Position is used in lots of places. For example LexAccessor. It should break plugins binary compatibility left and right.
This kind of demonstrates the difference between Windows mindset that holds binary compatibility sacred and Linux mindset that assume that packages are always built from sources and no binary should ever interact with different versions.

Somewhat surprising that Scintilla developers allowed this incompatibility so easily. I wonder if they realized the impact.

Plugin manager may mitigate the affect in case plugin developers will cooperate but in it is a real pity if newer plugins will not work with older Notepad++.

Depending of the amount of plugin breakdown that will occur @donho should consider if Notepad++ user base will not be served better by temporary rolling back Notepad++ to the older Scintilla and announce some 6 month to plugin developers to get ready for the change.

dail

@gstavi

Somewhat surprising that Scintilla developers allowed this incompatibility so easily

The Scintilla developers are not at fault. This is the entire reason they changed from the 3.x to 4.x version.

gstavi

@dail said:

The Scintilla developers are not at fault. This is the entire reason they changed from the 3.x to 4.x version.

It is very much in dispute whether a library should ever allow itself a major compatibility breaking change to its API. Changing the library’s major version does not magically justifies it. This is definitely the Linux mindset with its advantages and shortcomings.
A responsible developer should go through all possible hoops to extend the API rather than change it before going this path. Maybe they did, I don’t know.

Specifically for this change, I would challenge, the need to support 64 bit position within a document. Opening a text file over 1GB is such a bad user experience that I doubt that you can find 0.01% within your user base that do it routinely. Your guess is good as mine for the amount of users that will be pissed by the compatibility break.

Still need to audit plugins to see how many are actually broken. Maybe I am overly pessimistic.
But it is possible that 32 bit version of Notepad++ just became much more attractive.