Notepad++ 7.6.1

donho

There is a known bug in the unzipping code for plugin ZIP packages. If a plugin comes with companion files, plugin installer GUP.exe may produce 0-byte files when unzipping them. Affected plugins may fail to work.

See here, here and here.

It’ll be fixed in the next release. Thank you for the heads up.

pnedev

@donho said:

Which one? Could you provide me the path please?

Yes, %ProgramFiles%\Notepad++\plugins is the path. It contains only the disabled sub-folder.
This was the plugins location in versions prior 7.6.

Meta Chuh

@pnedev
in my case C:\Applications\Notepad++\plugins
(default install but custom location)
also contains the APIs folder containing c.xml and all others.
where is your APIs folder located ?

Meta Chuh

i’ve just tested a fresh install and all looks normal to me:

autoCompletion.nsh puts APIs into “$INSTDIR\plugins\APIs” (if autocomplete is not deselected when installing notepad++)

and AutoCompletion.cpp expects APIs there.

i personally don’t mind at all that the base folder for APIs is called plugins like it is now.

i would leave this as it is unless anyone really wants to clean up a lot more than just using a different folder name for $INSTDIR\plugins\APIs, except if everyone is willing to do a fresh install and to do a manual migration of their custom APIs if they have some.

dinkumoil

@donho

I have tested an update installation from v7.5.9 (32 bit) to v7.6.1 (32 bit) (local installation in directory %ProgramFiles(x86)%).

The installer of Notepad++ seems to have a hard-coded list of plugins which are considered to be unstable. One plugin on this list is the HEX-Editor plugin. The installer of v7.6.1 still moves it to <Notepad++-installation-folder>\plugins\disabled. This should be changed to the location where plugins are actually stored, particularly because the directory <Notepad++-installation-folder>\plugins will be removed in the future.

In general it’s the question if this hard coded plugin list is useful. I use the HEX-Editor plugin with my productive v7.5.6 installation and I’m not facing any problems.

pnedev

@donho , @Meta-Chuh ,

I understand now, thanks to @Meta-Chuh ’ s post.

During install I disable Autocompletion in the installer so the APIs are not installed.
I didn’t know those were put in plugins sub-folder as well. Now it makes sense why the plugins sub-folder is still in Notepad++ install folder.
I would prefer though to have
%PROGRAMFILES(x86)%\Notepad++\APIs
instead of
%PROGRAMFILES(x86)%\Notepad++\plugins\APIs
and remove
%PROGRAMFILES(x86)%\Notepad++\plugins altogether.
This helps avoid confusion in the future as plugins are not going to live anymore in Notepad++'s install folder (excluding here the portable variant).

dinkumoil

@donho @Meta-Chuh @pnedev

Regarding APIs directory: As far as I know there are plugins wich are indeed lexers for a certain language. I actually found the WLangLexer which is part of the plugin list of old Plugin Manager. This plugin requests during its installation to copy an XML file to plugins\APIs.

I don’t use lexer plugins, thus I don’t know anything about them. But I think further investigations have to be done before making a decision regarding plugins and plugins\APIs directories.

pnedev

Good point @dinkumoil ,
I don’t use additional lexers and missed that subtlety totally.

@donho ,

I just tried installing SessionManager plugin through 7.6.1 Plugin Admin - Notepad++ restarted but the plugin did not install. There wasn’t any notification about that failure. I believe we need to have some kind of status on plugin’s install - success, fail, progress…

Do you guys experience the same or it is again due to me using Wine?

pnedev

BTW, SessionMgr-1.4.2-plugin.zip stays as zero-bytes file in my user’s Temp folder after the installation fail. We should remove the plugin’s zip after the fail as well @donho .

pnedev

@donho , @dinkumoil , @Meta-Chuh ,

Perhaps the APIs sub-folder needs to be located also in %PROGRAMDATA% :
%PROGRAMDATA%\Notepad++\APIs
instead of
%PROGRAMFILES%\Notepad++\plugins\APIs
because of what @dinkumoil just pointed above - some lexer plugins might want to add some files to APIs as well.

dinkumoil

@pnedev

I miss installation progress too and when a plugin installation/update failed I was facing error messages that stated the wrong reason for that.

I already requested user feedback some weeks ago (see here). And @SinghRajenM has put some effort in writing code that extends GUP.exe to do so (see here and here). But for what ever reasons these PRs have been closed.

dinkumoil

@pnedev

We should remove the plugin’s zip after the fail as well @donho .

No! Gup.exe should be fixed. The plugin is the victim and not the cause of this error.

pnedev

@dinkumoil said:

… I was facing error messages that stated the wrong reason for that.

I assume Wine is the reason why I don’t get the error notifications then, thanks.

No! Gup.exe should be fixed. …

OK, it is perhaps this post of yours.

Meta Chuh

@pnedev

I would prefer though to have
%PROGRAMFILES(x86)%\Notepad++\APIs
instead of
%PROGRAMFILES(x86)%\Notepad++\plugins\APIs

it would be a cleaner, more logical structure, but at the moment there are many scenarios where it can break a functionality if you update an older installation, if they are not considered prior to coding the path changes, and i guess this means a lot of coding work for a cleanup which few people will ever notice or appreciate.

BTW, SessionMgr-1.4.2-plugin.zip stays as zero-bytes file in my user’s Temp folder after the installation fail.

it installs fine for me, but it is missing the menu title on both windows and osx.
alt

@donho
thanks again for the wine path and installer mods, all works like a charm so far. 👍

pnedev

@Meta-Chuh said:

it installs fine for me, but it is missing the menu title on both windows and osx.

It is Session Manager’s known issue that is fixed but not officially merged.

graphixillusion

I’m trying the new version, the portable one, but i can’t see the plugin manager anywhere. Any clue?

Ketrel

I cannot install any plugins in 7.6.1.
I load plugin admin, select the plugin I want, and choose install.

It tells me the program will need to be restarted.
I select ok, and then it closes, and launches a UAP prompt.
I approve that, and then the updater tells me there’s an updated version of Notepad++

If I say yes, it tries to install 7.5.9.
If I say no, it closes and does nothing further.

Upon manually reopening, the plugin I selected is NOT installed.

SinghRajenM

@dinkumoil said:

@pnedev

I miss installation progress too and when a plugin installation/update failed I was facing error messages that stated the wrong reason for that.

I already requested user feedback some weeks ago (see here). And @SinghRajenM has put some effort in writing code that extends GUP.exe to do so (see here and here). But for what ever reasons these PRs have been closed.

Not only this, but are other flaws too -

npp instance should not closed till operation is successful.
plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).
As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Cases:

Add: If a plugin is being downloaded first time, there is not point to close npp instance. download the plugin, then extract it to plugin install directory. Later ask user to restart to take immediate effect. However, on next restart the plugin will be activated by default.
Remove: simply move (using move api) the plugin dll from the install dir to %temp% and once done, ask user to restart. If user does not restart to take immediate effect, otherwise on next restart it will be effected anyway.
Update: First follow “remove” case strategy and then follow “add” case. Once both the cases done, ask user to restart npp or anyway it will take effect on next restart.

Of-cource failures should be handled for all the cases. And all the cases, extra column can content current progress.

chcg

@donho See https://github.com/notepad-plus-plus/wingup/pull/8 for the unzip issue. It fixes at least some aspects of the problem, also still some files are empty.

dinkumoil

@SinghRajenM said:

npp instance should not closed till operation is successful.

Good point, currently there is taken no means to prevent the user from restarting Notepad++ manually in the middle of plugin installation/update.

Imagine a plugin download takes a long time because of slow responding servers and the plugin DLL file is only written as a half. The user gets unpatient and starts Notepad++ manually -> crash, user is unhappy, complains here in the forum and tells his friends that Notepad++ is garbage.

On the other hand I have no idea how to prevent the OS to run a new instance of Notepad++. In the moment a piece of software can detect that a new Notepad++ process is running it is already too late.

plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).

As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Would be really good to have, but I’m afraid that it violates the KISS approach of @donho and thus we will never get it.

Remove: simply move (using move api) the plugin dll from the install dir to %temp%

I don’t agree. I think it is not possible or at least not a good idea to move a plugin DLL file while it is in use.

I think it’s worth to rethink about the whole concept of the plugin update process.

The download of plugin ZIP packages should be done by Notepad++ itself. This way it would be easy to provide a progress bar, meaningful error messages which reflect the real cause of an error and it would prevent users from manually restart Notepad++ because they could see that it is still running and does something. The downloaded ZIP packages should be stored to a subdirectory of the %TEMP% directory.
After downloading the ZIP packages, Notepad++ should start a helper program, depending on the installation scenario of Notepad++ with or without elevated rights, and terminates itself. I recommend to write a new software for that, I will explain below why.
The helper has to be called with an information where to find the ZIP packages and where to unpack them. It waits until there is no more running Notepad++ process. Then it loops over all downloaded ZIP packages found in the source directory and unpacks them to the given location. During this phase it displays a progress bar to provide user feedback.
Finally the helper program restarts Notepad++ without elevation.

Why do I think we need a new helper program for that?

The whole thing is a specialized task for updating plugins. GUP.exe was designed to be used as an application updater and it should stay to be that. Currently every change to the plugin updating code bears the risk to break the updating functionality of Notepad++. That alone is a good point to separate these tasks into two programs.

Furthermore we have currently the problem that portable installations of Notepad++ can not be shipped with GUP.exe because it would download an installer version of Notepad++ when users click to (menu) ? -> Update Notepad++. With a separate program for plugin updates this would be no issue anymore.

BTW: It is really annoying to explain users her in the forum again and again why portable versions do not contain Plugin Admin, this should be fixed ASAP, it doesn’t matter in which way.