Release 5.5.3 (https://www.scintilla.org/scintilla553.zip)
Released 19 October 2024.
On Win32 change direction of horizontal mouse wheel and touchpad scrolling to match other applications. Bug #2449.
Release 5.4.1 (https://www.scintilla.org/lexilla541.zip)
Released 19 October 2024.
Lexer added for Dart "dart". Pull request #265, Pull request #275.
Lexer added for troff / nroff "troff". Pull request #264.
Lexer added for Zig "zig". Pull request #267.
C++: Fix crash for empty documentation comment keyword where '<' occurs at line end.
F#: Include EOLs in the style range of SCE_FSHARP_COMMENTLINE. Stabilizes EOL detection when folding line comment groups. Issue #276.
F#: Fix per-line folding in F# documents. Issue #277.
HTML: Improve SGML/DTD lexing. Don't terminate SGML when > inside quoted string. Lex both [ and ] as SCE_H_SGML_DEFAULT. Nested sections handled instead of switching to SCE_H_SGML_ERROR. Issue #272.
JavaScript: New SCE_HJ_TEMPLATELITERAL and SCE_HJA_TEMPLATELITERAL styles for template literals when lexer is hypertext, or xml. Issue #280.
PHP: Fix failure to recognize PHP start "<?php' at end of document. Caused by not capping retrieval range at document end causing no text to be retrieved. Issue #269.
Smalltalk: Fix scaled decimal numbers without decimal separator. Pull request #274.
Fix#15228, fix#15368, fix#15650, close#15717
STR:
1. Open a network file.
2. Close Notepad++ to have it in the session.
3. Disconnect the network, and launch Notepad++ immediately.
4. Around more than 1 minute's delay, then the "Error" dialog displayed.
The reason for the hanging is that the network file was incorrectly detected by doesFileExist (GetFileAttributesEx) as present, leading Notepad++ to attempt opening a non-existent file with _wfopen. This issue seems to stem from a caching mechanism within the IO function (GetFileAttributesEx). When the network disconnects, the cache is not immediately cleared, causing GetFileAttributesEx to falsely report that the file exists. Consequently, when Notepad++ is launched after a network disconnection, GetFileAttributesEx retains its cache, indicating the file exists, while _wfopen fails to locate the network resource, resulting in a hang.
Unfortunately, there's no efficient solution for this problem. The commit's remedy is to check if the file is on the network and whether its directory still exists. If the directory doesn't exist, we avoid calling _wfopen. We verify the directory's existence instead of the file itself because the cache issue with GetFileAttributesEx occurs before _wfopen is executed. Checking the directory avoids the cache problem due to the identical argument being used.
I've tested this remedy in debug mode, and it works fine. However, the problem persists in release mode. Despite this, I believe it's worth keeping this solution, as it provides some protection in a variable network environment, potentially mitigating the issue when it arises.
Ref: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/15658#issuecomment-2386662974
Improve #4306, #6178, #8055, #11388, #12553, #15540, close#15701
This PR prevent hanging when user: Open a network file, modify it. Disconnect the network, then save the file.
It also prevents the zombie process due to blocked CreateFile left behind.
Remove the timeout thread for CreateFile to prevent the zombie process. Use another way for the detection:
If the result of network file existent detection is false, and the network problem found (timeout reached), we just stop and don't call CreateFile routine.
Ref: 1445487
Improve #4306, #6178, #8055, #11388, #12553, #15540
Add thread for CreateFile to fix saving disconnected network file hanging.
STR: Open a network file, modify it. Disconnect the network, then save the file. A huge latency (more than 1 minute) can be observed.
Not that the crash is not reproducible anymore by this PR. If any crash happens for you, please let me know (with the STR).
Ref: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/15669
Improve #4306, #6178, #8055, #11388, #12553, #15540Close#15679
Context: While the network file is disconnected, it's considered non-existent and might to be deleted.
The reason of crash:
"doClose" on the same buffer happens twice while users clicks X button, then chooses "No" when they are asked whether if this file should be kept in editor.
Explanation:
When user clicks X button on the tab of the file in question to close it, "activateBuffer" is called, then "fileClose" is called.
* activateBuffer: Following "activeateBuffer" call in the depth, "checkFileState" is invoked - that leads the message "The file "xxxxxx" doesn't exist anymore. Keep this file in Editor?". If user clicks on No, "doClose" will close the tab and destroy the buffer.
* fileClose: in "fileClose" call, "doClose" will be invoked and try to close the already-destroyed buffer.
Solution:
Retrieve the buffer ID once again, after "activateBuffer" call, for comparing with old buffer ID. If the buffer was destroyed, the new retrieved buffer ID is not the same.
Note: this commit fixes the crash, but it doesn't fix the misbehaviour: If user clicks on "Yes" to answer the message "The file "xxxxxx" doesn't exist anymore. Keep this file in Editor?", the tab will be still closed.
Fix#15684, close#15685
Refactoring for reducing the I/O calls, fix typos.
Reduce the startup time (while the a dirty disconnected network file is in the session) from about 12-15 seconds to about 6 seconds (on my laptop).
Note that there are 2 cases are not improved by the commit:
* STR 1: Open a network file, modify it. Disconnect the network, then save the file.
There will be a huge hanging time (around 1 minute) to get the warning dialog.
I tried to remedy with thread for CreateFileW in the constructor of Win32_IO_File, however it leads crash due to the lock guard in the caller.
* STR 2:
1. Open a network file.
2. Close Notepad++ to have it in the session.
3. Disconnect the network, and launch Notepad++ immediately.
4. Around more than 1 minute's delay, then the "Error" dialog displayed.
The reason of hanging is that the network file was detected by "doesFileExist" as true, so Notepad++ was trying to open non-existent file (by _wfopen).
I believe that there's some kind of cache during the very short period for the IO function (here's our case GetFileAttributes), and such cache is not immediately synchronized (cleared) while network disconnected. As a result, when we launch Notepad++ after the disconnection of network, GetFileAttributes keeps its memory & responds "FileExists". However for _wfopen it doesn't see the resource of network anymore - that makes hanging.
Ref #15658
Improve #4306, #6178, #8055, #11388, #12553, #15540Close#15669
The issue is due to WinAPI's GetFileAttributes function can take a huge amount of time in various situations, like when the target server being offline (usalally).
The current solution is to wait at least 3 seconds for each GetFileAttributes function, then return the default value in case of the problem (or the returned value of the function, in case of normal situation - if it has been executed completely during the 3 seconds).
So there'll still be the hanging time (3 or 6 seconds) while the problem of network connection, but the hanging time (it could be 30 seconds more) is reduced considerablly.
"Wow64EnableWow64FsRedirection" call is also removed from x64 build (in which this call is unnecessary) in this commit to reduce the IO calls.
Fix#4306, fix#6178, fix#8055, fix#11388, fix#12553, fix#15540, close#15658
Note: while create the new tab (empty & clean), there will be a created time displayed. When the document is modified and period backup feature is enabled, a new created time will be assigned and displayed. However, the time of the first modification which makes empty document dirty will be remained as the tab creation time, even with several modification afterward.
Fix#15563, close#15651
Update translation texts for these commits:
* Make C-Like indent deactivatable (439bbb0)
* Improve description for settings "Backup" (108b9f0)
* Add missing localization for debug info dialog and print error (ea5e36a)
Close#15455
kubalav