Notepad++ v7.6.2 Yellow Vest (Gilet Jaune) Edition
is it intional, that foreign installed plugins in ProgramData are not deleted by uninstalling even if user decides to remove all NPP settings?
I fear that is this uninstall is done to cleanup, old (maybe 32-bit) plugins pollute a possible new installation…
If you don’t mind, I would vote for deleting all directory content in (%ProgramData%|%AppData%)…\Notepad++
in this case.
Sorry was already discussed with @pnedev 8 days ago.
Vote for deleting complete folders would still be my vote ;-)
I noticed utf-8 not working in all cases
Fresh install (v7.6.2) (do not keep settings)
write “abcd” in file - save and reopen - everything is fine, it is still utf-8
Add “ü” - save and reopen - it is ISO 8859-7
I forget to mention, that before adding the “ü” there had do be a newline (Windows CR LF) inserted
“abcd\nü” changes utf-8 to ISO 8859-7 on reopening.
Besides, this is a regression, already existing in 7.6
PS: I can only edit post the first 3 Minutes, But I can only add a new post after 20 Minutes
welcome to the notepad++ community @Monika-Lobinger
unfortunately the last update to “autodetect character encoding” is not working properly, so you have to disable it for now, to avoid the sequence
\nüto be detected as greek.
go to settings > preferences > misc., and deactivate “autodetect character encoding” as seen in the screenshot below.
i’ve already filed a bug report for french at github
and i hope it get’s looked at in the near future.
little technical info, if it is of interest:
the auto detection engine UCharDet was updated to 0.0.6.
the UCharDet 0.0.6 engine itself works fine, but there seems to be a bug in it’s implementation to notebook++.
i’ve tested UCharDet as a stand alone program on the same documents, and all tested documents are detected correctly.
if auto detect encoding is enabled, and a file is not detected correctly, for example greek as in your case, you also will not be able to set it to utf-8 by clicking on encoding > encode in utf-8. it will deselect utf-8 automatically and the bullet will jump back to eg. 8859-7.
btw: thanks for taking your time to find out and break down which character sequence triggers it for you.
i can also confirm, that a text file with only an utf-8
\nüand no other text in it will also be detected as greek ISO 8859-7.
Hi guys, recently packaged NPP 7.6.2 64bit edition, and installed the 64Bit versions of XML Tools and ComparePlugin - that were working fine with NPP 7.6.1 or lower (till 7.5.8 I have tested).
The issue now is that the plugins are not displayed under Plugins tab with the latest version.
Is this know or? Is there any solution to this inconvenience?
welcome to the notepad++ community @Shizdenn
and sorry for the inconvenience.
you will have to move your plugins from:
%LOCALAPPDATA%\Notepad++\plugins(location in 7.6.1)
%PROGRAMDATA%\Notepad++\plugins(location since 7.6.2)
as the location of the plugins have changed once more (and they will hopefully stay there 😉 ).
afaik. the reason for this change were many requests, to make it possible to use the same plugins for all users, instead of having to install them separately for every user account.
(the past location %LOCALAPPDATA%\Notepad++\plugins has lead to a separate folder for each user, eg. C:\Users\[AnyUsername]\AppData\Local\Notepad++\plugins)
thanks for your commit List plugins in alphabetical order in Plugins Admin dialog.
i’ve just tested it and it works like a charm.
much appreciated as always.
Hi team, @donho, @pnedev
I hope by plugin re-ordering the DEV do not change the way how plugins are actually loaded to NPP. It is good to keep alphabetical order of loading wile _ is after the normal letters (please confirm)
The _CustomizeToolbar actually relies on that sequence to come to the game as the last loaded. That’s why the name was changed with underscore _,
Otherwise, all plugins loaded after it (with name > Cu…) had only an arbitrarily 10mS waiting idle time that plugin waits/idles itself for them to finish. If a heavy loadin plugin like SpellCheck do comes later, then CustomizeToolbar does not see it and custom button of it will be an Error (grayed out) It happens on slow PC’s
don’t worry, this is only for the plugins admin’s listing order, not the menu.
the plugins menu itself keeps the same order as you are used to, seen at the screenshot below:
I now regret making these two posts:
The amount of suppression that the Yellow Vest protest has received has now made me think that raising awareness of it, even in this way that I typically do not advocate, is acceptable…
Please delete these posts, and this one too.