v8.4.2 bug
-
Probably start by removing all plugins and seeing if that behavior persists.
-
After using Notepad++ for many years without issues, version 8.4.2 was a surprise for me too a few days ago.
On my work laptop it installed and runs flawlessly, as usual. But on my more powerful desktop computer at home, the newly installed application refused to even start. I tried removing all plugins, then a complete uninstall and fresh install. Neither worked. As soon as I installed 8.4.1 again though, it worked without a hitch. So I hope 8.4.3 will not have this bug.Both computers are running fully updated versions of Windows 10 Pro on 64-bit Intel Core CPUs.
-
@bibliothecarius77 said in v8.4.2 bug:
As soon as I installed 8.4.1 again though, it worked without a hitch.
Like any installation it can happen that the install itself failed to complete or that one or more files within became corrupted. This does not make it a bug. Generally when the question of a troubled installation occurs the steps are generally to run without plugins first, then clear out user config files and failing that a complete uninstall, clearing of the folders associated with the install (both program files and local user config files) before reinstalling.
It’s good that you managed to overcome it though.
Terry
-
@terry-r
Actually Terry, I’ve confirmed someone else’s issue with this. I delayed updating with the autoupdate, and when I did the autoupdate from the?
menu selection, and popped up offering to remove the CSVLint plugin…but it never does and clicking the icon of the desktop with theinstalled
version, just keeps popping up that pop-up instead of doing it.
I can’t post a debug shot because it’s not starting up. :(
-
@lycan-thrope ,
Okay, so I went in and manually had to remove the CSVLint folder from theC:\Program Files\Notepad++\plugins
folder and then double clicked the desktop icon and it came up with this debug info.Notepad++ v8.4.2 (64-bit) Build time : May 29 2022 - 16:47:30 Path : C:\Program Files\Notepad++\notepad++.exe Command Line : $COMMAND_LINE_PLACEHOLDER$ Admin mode : OFF Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 10 Home (64-bit) OS Version : 21H2 OS Build : 19044.1766 Current ANSI codepage : 1252 Plugins : CsvQuery (1.2.8) mimeTools (2.8) NppConverter (4.4) NppExport (0.4) NppXmlTreeviewPlugin (2) PlantUmlViewer (1.1.1.5) XMLTools (3.1.1.12)
So I’ll go post the fix in that other thread, but this is a short coming of the program installation, that it asks if you want it removed and then doesn’t do it.
-
@lycan-thrope said in v8.4.2 bug:
Actually Terry, I’ve confirmed someone else’s issue with this.
I think you’ll find the problem mentioned in this thread isn’t the CSVLint one, otherwise the OP would have mentioned it. He just said it “refused to even start”.
Of course he may have that issue, but as he was rather light on details we’ll never know. At least he “downgraded” and got going again.
Gotta love a major re-hash in NPP which then means a LOT of fallout with plugins which may be going on for months!
Terry
-
@terry-r ,
Yes, and now I have to find the place to report this bug. :) -
@lycan-thrope said in v8.4.2 bug:
and now I have to find the place to report this bug
If Notepad++ isn’t removing a plugin when it asks you to and you say Yes (I’ve seen this behavior as well), then the normal Notepad++ issue tracker is where to report it; see the FAQ on this site.
@terry-r said in v8.4.2 bug:
Gotta love a major re-hash in NPP which then means a LOT of fallout with plugins which may be going on for months!
I suppose the alternative is a stagnant N++! :-)
-
@alan-kilborn said in v8.4.2 bug:
I suppose the alternative is a stagnant N++! :-)
Don’t misunderstand. I’m all for progress. It’s the fallout that seems avoidable. Amazing how many users are upgrading because NPP says so, only then to find their plugin kills it.
I don’t know what the alternative should be, but there must be a better solution that what we’re seeing on the forum currently. It seems almost every 2nd post is about the plugin incompatibility issue with the latest NPP version. And as some plugin developers will likely take some time to update their plugin I can see this continuing some months.
Terry
-
@terry-r said in v8.4.2 bug:
but there must be a better solution that what we’re seeing on the forum currently. It seems almost every 2nd post is about the plugin incompatibility issue with the latest NPP version
I suppose the best we can do is a FAQ entry.
Then support becomes “See the FAQ” and, before it becomes too tiresome, possibly copying a direct link to the appropriate FAQ entry.I’m open to better suggestions, in fact, I’d love one.
-
@alan-kilborn said in v8.4.2 bug:
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 ,
Official report:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11819 -
@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.
-
@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?
-
-
-
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 theADD_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.
-
This post is deleted! -
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
-
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.