v8.4.2 bug

Terry R

I suppose the best we can do is a FAQ entry.

Probably, but then I think you must be having a laugh. How many times do we get OPs asking questions without having first read the “pinned” posts. We refer them back to that post so they may provide better information or more importantly examples we can trust haven’t been munted by the interpreter. They hardly ever do even when it’s in their face.

I will say though that @PeterJones must have the stamina of an ox to repeatedly help those who don’t wish to even raise a finger themselves!

And we expect them to read a FAQ section? :-)))

Terry

Lycan Thrope

@lycan-thrope ,
Official report:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11819

Alan Kilborn

@terry-r said in v8.4.2 bug:

And we expect them to read a FAQ section?

Nope. But the quick response by someone here of “read FAQ” is fairly quick.

PeterJones

@alan-kilborn said in v8.4.2 bug:

I suppose the best we can do is a FAQ entry.

How is this for a FAQ entry?

https://community.notepad-plus-plus.org/topic/23146/faq-desk-notepad-crashes-freezes-unresponsive-after-update

Alan Kilborn

@peterjones said in v8.4.2 bug:

How is this for a FAQ entry?

It’s simply amazing! :-)

PeterJones

@alan-kilborn said in v8.4.2 bug:

It’s simply amazing! :-)

Have fun pasting that link a lot. ;-)

rdipardo

@peterjones,

Possible Culprit: Plugin
. . .
in v8.3, Notepad++ updated the communication protocol between plugins and the application to better handle large files (>2GB) which required all plugins that used certain protocol calls to release a new version.

What they really did was increase the size of Scintilla’s TextRange structure to accept character positions >2,147,483,647, and only in x86_64 builds. That changed the ABI because it’s machine-dependent. A change to the “communication protocol” or API would be adding or removing a function parameter, like the ADD_ZERO_PADDING wPARAM in v8.4.1.

Breaking the ABI for the sake of one rarely used feature was pretty reckless, but it would never be a problem if:

plugins were dynamically loaded scripts, as they are in Vim, Sublime Text or VS Code
plugins could never call into Scintilla’s APIs; a baby-proofed FFI could be provided, but no direct calls into any C++ functions, ever

Somebody is bound to figure this out and fork N++ to include the equivalent of Vim’s Python interface. Static linkage with some form of PythonScript’s code base would be the quickest way. A plugin of the future would be just a Python module that users can fix or adapt all by themselves. Slower performance than DLL plugins, yes, but not noticeably so on recent hardware.

PeterJones

This post is deleted!

PeterJones

@rdipardo ,

That changed the ABI because it’s machine-dependent. A change to the “communication protocol” or API would be adding or removing a function parameter

I will rephrase it to “rules” rather than “protocol”. It doesn’t need to be any more technical than that for a FAQ entry for normal users

rdipardo

The main point to make is that only 64-bit plugins need to be scrutinized for 8.3 compatibility, so a user doesn’t mistakenly trash a perfectly safe 32-bit plugin.

PeterJones

@rdipardo ,

The debug instructions don’t trash anything – they temporarily rename a folder. I believe it is a solid debugging plan to try to narrow down where the problem is coming from. There are times when the plugin is at fault, even if it’s not because of the 64bit-only change in Notepad++.

But since it bothers you, the paragraph now emphasizes 64bit for the v8.3 change:

in the 64bit Notepad++, v8.3 updated the communication rules between plugins and the application to better handle large files (>2GB) which required all 64bit plugins that used certain protocol calls to release a new version.