Implement support for Win32 Namespace prefixed file name in Notepad++.
(Ref: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces)
Support the Win32-filenames escaped by \\?\ or \\?\UNC\, possible globbing in filenames (\\?\C:\fil?.txt) and shell links (\\?\C:\file.txt.lnk) included.
Unsupported (temporarily - it needs further patches for Notepad++):
- any raw filename with length exceeding the MAX_PATH.
- any nonstandard Windows OS filename: with 'dot' or 'space' char(s) at the name end, WinOS reserved ones: AUX, CON, PRN, NUL, COM1-9, LPT1-9 and the ones with invalid ASCII chars in it (0-31, <, >, | , ").
Fix#12453, close#12613
1. Rename some labels to be more explicit.
2. Add a tooltip for "Deactivate Word Wrap globally".
3. Unchecking "Enable Large File Restriction" removes the sub-restrictions.
Background: because styling large file can cause the performance issue, 200 MB (and bigger) file is not applied to its language (if any) while loading.
This PR makes large file restriction for styling and for other features (smart highlighting, brace match, etc...) configurable via the section Performance of Preferences dialog.
Fix#11389, fix#12260, fix#11670, close#12310
Properly handle missing file extensions in `Buffer::setFileName`
Before 6263ce5, the user-preferred default language would apply to
files with no extension, but got overwritten by `L_TEXT` when the
extension was present *but unknown*.
This is why the `buf->_lang == L_TEXT` condition failed *only for
buffers with _no_ extension*.
Fix#11504, close#12286
Fix detected language not being applied if Default languge is set in Document settings.
Don't override detected file type with default language:
When loading files with no extension from disk, remove the extra condition so the default language setting does not take precedence over the auto-detected file type (if any)
Fix#11504, close#11992
Make external lexer library work again after upgrading to Scintilla5.
Old external lexer libraries needs to add CreateLexer export function which returns ILexer5 instance (Lexilla protocol interface of Scintilla5).
Tested with papyrus lexer plugin, this external lexer plugin is compatible with Notepad++ next release:
https://github.com/blu3mania/npp-papyrusClose#11468
Update with https://www.scintilla.org/scintilla521.ziphttps://www.scintilla.org/lexilla515.zip
- fix setting to bring Scintilla::PositionCR from ScintillaStructures.h inline with Sci_Position.h Sci_PositionCR
- add workaround to enable lexer for searchResult
commented out SCI_SETILEXER call on searchResult to get one result which is correctly handled by the lexer,
added comment about the current problem with property @MarkingsStruct which seems to disappear after call to SCI_SETILEXER or CreateLexer
- corrected usage of ObjC lexer
- removed unnecessary filter stuff
- use own sections for scintilla and lexilla build targets and allow parallel builds
- as libscilex is no longer existing, changed to libscintilla
- adapt makefiles and cmake
- use VS2019
- started simple changes for createlexer adaptations, nullpointercheck missing on return of lexer name from deprecated LexerNameFromID -> undefined behaviour
- movement from id -> lexer name, mostly done via LexerNameFromID + switching off corresponding compiler warning
- changed to SCI_SETILEXER from SCI_SETLEXER, SCI_SETLEXERLANGUAGE needs to be corrected, see Scintilla5Migration.html
- just commented out: SCI_LOADLEXERLIBRARY
Fix#10504, close#11419
Implement: https://github.com/notepad-plus-plus/nppPluginList/issues/416
While PluginAdmin loading nppPluginList.dll, it will check an attribute "npp-compatible-versions" (optional),
in order to determinate if plugin is compatible to the current version of Notepad++. If plugin is not compatible,
then this plugin will be ignored, therefore it won't be shown on the PluginAdmin's plugin list.
Note that it's only about pluginsAdmin's plugin list:
it prevent from Notepad++ install/update a plugin non-compatible to current version of Notepad++,
but it still allows Notepad++ load this plugin in question, if it's already installed.
Here is the attribite "npp-compatible-versions" looks like in plugin list json file:
```
{
"name": "npp-pluginList",
"version": "1.4.7",
"arch": "32",
"npp-plugins": [
{
"folder-name": "demoPluginA",
"display-name": "Demo Plugin A",
"version": "1.8.7",
"npp-compatible-versions": "[4.2,6.6.6]",
"id": "9c566a9083ef66a0ce93a3ce5f55977faea559b5b0993e37a1461b87f4aeb6f0",
...
},
{
"folder-name": "demoPluginB",
"display-name": "Demo Plugin B",
"version": "1.1.8.7",
"id": "8a6b9dadbf2ec37d5c60a12a5445f0eec2ef00e6eaa80452925789fd73950193",
...
},
...
}
}
```
It's optional. In the case of its absence, it's considered compatible to all versions of Notepad++.
The format of value for "npp-compatible-versions" is following (no white space is allowed):
"6.9" : exact version 6.9
"[4.2,6.6.6]" : from version 4.2 to 6.6.6 inclusive
"[8.3,]" : any version from 8.3 to the latest one
"[,8.2.1]" : 8.2.1 and any previous version
Fix#11338, close#11334
In FileManager::loadFileData method:
1. Fix unnecessary GCC crashes when opening larger files in 32-bit Notepad++ binary.
2. Take into account and report correctly also other possible Scintilla error states there (than the previously handled SC_STATUS_BADALLOC).
3. Catch and report correctly also exceptions not handled by the Scintilla exception handler.
4. Catch and report correctly also Notepad++ code exceptions there.
Fix#11103, close#11112
While loading files over more 200MB, they are all considered as Normal text files, that improve loading speed (for example for huge XML or SQL file).
Also, the feature as braces match, smart highlightingg, tag match and URL colorization are disabled for not penalizing the editing performance.
These logs are written for debugging NUL file-corruption issue (#6133) and session lost issue (#10402) which are still problematic probably.
The writting log info will be triggered only when Windows notifies Notepad++ to end session.
The log file will be in "%APPDATA%\Notepad++\" or in Notepad++ installation folder if doLocalConf.xml is present.
To disable the log, just remove nppLogNulContentCorruptionIssue.xml.
Close#10871
And add log ability for debugging network drive file status detection issue.
To activate log, user should:
1. Add an empty "nppLogNetworkDriveIssue.xml" file beside of notepad++.exe, or if user has no admin previlege, he/she can add this file into %APPDATA%\Notepad++\.
2. Create "C:\temp\" directory, if it doesn't exist yet.
3. Start notepad++.exe, and wait for the file status (timestamp) detection error from the network drive. If the errors occur, there should be some trace in "C:\temp\nppLogNetworkDriveIssue.log".
People who have had the network drive file status detection issue in #10688, #10753, #10757, #10751 & #10787 are welcome to download the binary and provide the generated log in order to fix this issue.
Fix#10751, fix#10688, fix#10753, fix#10757, fix#10751, fix#10787, close#10847
This regression is due to the saving routine's change:
9aa9ecb664
Normally, on each save, buffer's timestamp is updated for the future comparison with the timestamp on the disk, in order to detect the modification from outside.
It seems the new saving routing makes the change (ONLY on network disk) with the timestamp before buffer's timestamp, for unknown reason.
The fix is: if timestamp got directly from the file on disk is earlier than buffer's timestamp, it's an absurd case and we ignore it. The buffer's timestamp will be only updated if the file on disk timestamp is later than buffer's one.
Fix#10688, fix#10753, fix#10757, close#10774
The PR fixes the regression due to the saving file API being changecd from POSIX functions to Win32 native API:
The old used function "fopen" using "wbc" as argument, according Microsoft document:
"w" Opens an empty file for writing. If the given file exists, its contents are destroyed.
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160)
so to save a 0 length document, it was unecessary to "write nothing" explicitely on disk, since fopen did it for you.
Whereas our new implementation which uses Win32 native API passes "OPEN_ALWAYS" - that needs to "write nothing" explicitely.
Fix#10699, close#10702
This PR make buffer always dirty (with any undo/redo operation) if the editing buffer is unsyncronized with file on disk.
By "unsyncronized", it means:
1. the file is deleted outside but the buffer in Notepad++ is kept.
2. the file is modified by another app but the buffer is not reloaded in Notepad++.
Note that if the buffer is untitled, there's no correspondent file on the disk so the buffer is considered as independent therefore synchronized.
Fix#10401, close#10616
1. Rename CFile to Win32_IO_File (plus some modification in class).
2. Add new method writeStr() in Win32_IO_File class to write "char*" & string.
3. Change method names of Utf8_16_Write class and make writeFile() method return accurate type (boolean).
Close#10612
Uses native Win32 IO API (CreateFile, ReadFile, WriteFile, CloseHandle) instead of POSIX ones (fopen, fread, fwrite, fclose) for remedying NUL file-corruption problem due to system shutting down brutally.
Fix#6133, close#10598
