Several UDL xml files can be loaded to allow to manage/share UDL more easily.
1. The old file userDefineLang.xml is kept in its old location and is still used.
2. The new folder userDefineLangs is added beside of the old UDL default file. Any UDL xml file can go into the folder userDefineLangs and will be loaded as UDL.
3. A UDL xml file must contain one (or several) user defined language(s).
4. The created UDL via UDL dialog and imported UDL are saved in userDefineLang.xml (default UDL file).
https://notepad-plus-plus.org/community/topic/17072/new-enhancement-for-user-defined-language-system
Unexpect behaviour: if "<NppDir>\...dll" and/or "<NppDir>\plugins\..dll" exist, they will be loaded because Notepad++ try to load "<NppDir>\pluginName\pluginName.dll" as plugin, in our case "<NppDir>\plugins\..\...dll" and "<NppDir>\plugins\.\..dll" respectively.
The fix is excluding both directories ".." & "." to not load mentionned above unwanted dll.
Notepad++ launches updater (gup.exe) without checking the signature, that makes exe hacking possible.
The fix is to check updater binary's signature before launching it.
When the amount of clipboard data is too important, it makes crash of function WideCharToMultiByte (win32 API).
The remedy is to capture this error to prevent Notepad++ from crash.
Summary of the Issue:
A remote code execution (RCE) vulnerability was found when a user opens a crafted containing folder in the command line. Code execution is possible by injecting a & followed by system commands into the name of the folder.
Steps to reproduce:
Download the attached archive on Windows: unzip_me.zip (F404758)
Unzip it and navigate into it
Open the txt file inside with Notepad++
Go to File -> Open containing folder -> cmd
Impact statement:
Successful exploitation of this vulnerability would allow an attacker to remotely execute arbitrary commands on the victim's computer.
Inexistent path %APPDATA%\Notepad++\plugins\Config\ made some plugins crash.
In this PR the folder is checked (and created if it doesn't exist) by each launch of Notepad++.
Loading plugin list location is changed from %LOCALAPPDATA%\Notepad++\plugins\Config\ to
%PROGRAMDATA%\Notepad++\plugins\Config\
Enhance API NPPM_GETPLUGINSCONFIGDIR
Close#5037
User @buggalicious found the summary text is displaying a count of characters without line endings not blanks.
Patch should address #3849 by updating the text to describe what is actually being counted.
checked all files of the APIs dir for xml syntax issues and corrected the invalid files
Tested with plugin tools and checked also against https://www.xmlvalidation.com/
The current invalid xml syntax seems to have no bad influence on the functionality of the files.
Notepad++ loads plugins only from 2 locations:
1. %PROGRAMDATA%\Notepad++\plugins\ - while Notepad++ installed on: %PROGRAMFILES%\Notepad++\ or wherever without doLocalConf.xml
2. <NPP_INST_DIR>\plugins\ - while Notepad++ installed on wherever (except in %PROGRAMFILES%\Notepad++\) with doLocalConf.xml
- Fixed "Chinglish" Grammar (Original Chinese translator's defence: they are not "Chinglish", they are good Chinese translations which are not accepted by "normal people", who lakes the imagination and creactivity)
- Unified Translation for some terms
- `$STR_REPLACE` -> `$STR_REPLACE$`
- Added Several Translation
While plugins are in %PROGRAMDATA%, we need admin's rights to modify them. This PR detects the plugins installation in %PROGRAMDATA%, then launch wingup with UAC.
This PR contains three types of changes:
1. Actual bug fix. This bug appeared, because prior to closing files, "Close all but this" attempts to save modified files, and for that it needs to switch views. Those views were not restored after that, however - so further actions could end up being executed on a wrong view. Those are changed commented with // We may have to restore previous view after saving new files.
2. Another potential bug fix. Closing files in both views could result in views being switched (it may or may not, I did not manage to unambiguously find that out from the code). To prevent any possible issues, I stored view IDs in viewNo. If those could never switch, then the code changes nothing - but if they could, it fixes a potential bug.
3. Code clarity fix in Notepad_plus::switchEditViewTo. std::swap makes it more obvious this code is there only to swap values around!
Fixes#4911, Close#4920
Use the _isFolding flag to fix several overlooked edge case hangs.
This pull request fixes additional hangs I found after #4867 when working with deeply-nested fully-folded files. The hangs are easy to reproduce by following these steps:
Download the sample file https://raw.githubusercontent.com/notepad-plus-plus/notepad-plus-plus/master/PowerEditor/src/Parameters.cpp
Open the downloaded file by itself in NPP and fold it using Alt-0
Create a new empty tab and remain focused on it
Perform the six actions below, each of which will produce a hang as NPP tries to change focus back to the first tab. On my machine, each hang lasts about 30 seconds. After control returns, refocus the empty tab again and try the next action.
Use File>>Open to reopen the downloaded file, even though it is already open
Drag and drop the downloaded file onto NPP to reopen it
Double-click the downloaded file to reopen it
Right-click the downloaded file and select Edit with Notepad++ in the context menu
Open the downloaded file from the command line: C:\Program Files (x86)\Notepad++\notepad++.exe" .\Parameters.cpp
Click the red [X] in the upper right corner to close NPP
After applying the patch, none of the hangs should happen any more.
Close#4999
This PR fixes UTF-8 detection for 4 byte characters (a 2002 code used by npp assumed characters longer than 3 bytes are invalid -.-). This means such files will not be erroreously displayed as ANSI anymore.
Steps to reproduce:
Create a new UTF-8 file (w/out BOM)
Paste eg. this character 🍪 and save.
Reopen the file again.
Prior to this PR, file is detected as ANSI (even if Notepad++ is configured to default-assume UTF-8!!!). After this fix, file gets opened as UTF-8 correctly.
Fixes#4730, Fixes#3986, Fixes#3441, Fixes#3405, Closes#4922
The new message NPPM_GETPLUGINHOMEPATH allows plugins to get plugin home root path. It's useful if plugins want to get its own path by appending <pluginFolderName> which is the name of plugin without extension part.
Simply plugins loading emplacement:
NPPM_GETAPPDATAPLUGINSALLOWED to check to see if loading plugins from "%APPDATA%\..\Local\Notepad++\plugins" is allowed.
If doLocalConf no
else yes
1. Load plugins only from the new plugin folder structure. example: Notepad++\plugins\myAwesomePlugin\myAwesomePlugin.dll
2. Load plugins from only one directory. If doLocalConf.xml is present, then it will be <NPP_INSTALLATION_DIR>\plugins\
otherwise %USERPROFILE%\AppData\Local\Notepad++\plugins\
Old installation behaviour is loading installed plugins without restart Notepad++, which could make some plugins loading uncomplete.
New behaviour use the same implementation of plugin updating, witch quit notepad++ for plugin installation then restart Notepad++.
For the sake of retro-compatibility, change the way of plugin packaging:
1. The plugin DLL file should be placed at the root level of the ZIP file. It has to be the only DLL file on this level.
2. The root level of the ZIP file can also contain additional files and folders which will be copied to the users harddisk as well.
3. Everything what gets copied from the ZIP file will be stored under <Npp-installation-folder>\plugins\<plugin-name>.
Use the _isFolding flag to avoid expensive redundant operations that cause an apparent hang when opening or switching tabs to a large fully-folded file.
The released version of Notepad++ uses the _isFolding flag to avoid expensive redundant operations when switching to a fully-folded tab using the mouse pointer.
However, opening a fully-folded file or switching to a fully-folded tab with the keyboard can produce a delay so long that Notepad++ appears to hang forever.
The hang is 100% reproducible and can be demonstrated in less than 60 seconds:
Download a deeply-nested file such as https://raw.githubusercontent.com/notepad-plus-plus/notepad-plus-plus/master/PowerEditor/src/Parameters.cpp or https://github.com/notepad-plus-plus/notepad-plus-plus/files/1555939/nppTest.zip
Open the file in Notepad++ and fold it using Alt-0
Create a new empty tab
Switch back and forth between tabs using the mouse, which is fast
Switch back and forth between tabs using the keyboard (Ctrl-Tab, Ctrl-Page(Up|Down), Ctrl-NumPad[0-9]), which will hang
This pull request applies the existing _isFolding flag to the forgotten keyboard and file open operations and prevents the hang caused by opening or switching tabs to a fully-folded file.
Fix#3996, fix#1128, fix#1806, fix#4871Close#4867
Steps to Reproduce the Issue:
1. Open two files a.txt (first tab) and b.txt (second tab)
2. Start tail monitoring for a.txt (first tab) and activate b.txt (second tab)
3. Now delete a.txt from the explorer
4. Come back to notepad++
5. Observe the behavior now
Unexpected Behavior:
At step 4, if user choose to keep the file, a.txt is still marked as monitoring. As soon as del action occurs, b.txt automatically comes under "tail monitoring".
If user choose to remove file, a.txt should be removed from the notepad. This is absolutely fine.
Fix#4750, close#4751
Short problem description:
Drag/drop a tab with the mouse to another position,
then all other tabs can't be activated with clicking anymore.
Also a missing include was added, that prevented compilation
Fix#4885, close#4886
When we are restoring a wrapped buffer,
we send SCI_VISIBLEFROMDOCLINE message to convert a file line number to a visual line number,
scintalla seems to ignore the "wrap" option of this buffer.
Workaroud: execute SCI_ENSUREVISIBLE after set position and before executing SCI_VISIBLEFROMDOCLINE.
It seems that this issue has been encountered in ScitillaComponent/FindReplaceDlg.cpp in Searching::displaySectionCentered
Fix#4571, close#4624
Don HO