Update to scintilla 5.5.5 & Lexilla 5.4.3#16235
Update to scintilla 5.5.5 & Lexilla 5.4.3#16235chcg wants to merge 1 commit intonotepad-plus-plus:masterfrom
Conversation
Release 5.5.5 (https://www.scintilla.org/scintilla555.zip) Released 25 February 2025. Remember selection with undo and redo. Controlled with SCI_SETUNDOSELECTIONHISTORY. Feature notepad-plus-plus#1273, Bug notepad-plus-plus#1479, Bug notepad-plus-plus#1224. Serialize selection type and ranges with SCI_GETSELECTIONSERIALIZED and SCI_SETSELECTIONSERIALIZED. For Win32, update Direct2D and DirectWrite interfaces used to 1.1 and add a lower-level approach to calling DirectWrite 1.1 by specifying SC_TECHNOLOGY_DIRECT_WRITE_1. Since Windows Vista does not support these API versions, Scintilla o longer supports DirectWrite on Windows Vista and will fall back to using GDI. Fix segmentation of long lexemes to avoid breaking before modifiers like accents that must be drawn with their base letters. For wrapping, try to break lines without separating letters from modifiers. For GTK on Windows, replace reverse arrow cursor with hand as reverse arrow was small in scaled modes. Bug notepad-plus-plus#2460. Fix bug on Qt where double-click stopped working when Scintilla instance had been running for weeks. Release 5.4.3 (https://www.scintilla.org/lexilla543.zip) Released 25 February 2025. C++: Fix evaluation of != in preprocessor condition. Issue notepad-plus-plus#299. Modula-3: Allow digits in uppercase identifiers. Issue notepad-plus-plus#297. Pascal: Fix asm style extending past end. Issue notepad-plus-plus#295. Python: Fix detection of attributes and decorators. Issue notepad-plus-plus#294, Pull request notepad-plus-plus#302. Ruby: Implement substyles for identifiers SCE_RB_IDENTIFIER. Ruby: Recognize name as SCE_RB_DEFNAME in def when `::` used as well as `.`. Issue notepad-plus-plus#300.
|
Related N++ issues mentioned in ScintillaOrg/lexilla#294:
Further fixed issue: |
|
Unfortunately I have Platform asserts with the debug build from SurfaceD2D::MeasureWidths(), not sure if this is new to this PR. File is a bmp (https://github.com/chcg/NPP_HexEdit/blob/master/HexEditor/res/hex.bmp) With the release build there seems to be no problem arising from this. |
Could you provide me the instructions to reproduce the asserts please? |
donho
left a comment
There was a problem hiding this comment.
Were 2 headers added by accident?
@chcg |
|
Happens to me also with x64 debug build of 8.7.8 from https://github.com/notepad-plus-plus/notepad-plus-plus/actions/runs/13733461955/artifacts/2714893369. It is just necessary to open the bmp file mentioned above. |
I cannot reproduce with the local build from my machine:
Edit: cannot reproduce also with the binary from the link you provided above |
|
I can't reproduce the assertion failure either. The top half of the stack trace, above the second There are 3 assertions that may be triggered in
|
From the Debug Info, the OS of @chcg is Windows 10 Home, so what you have said makes sense. |
|
I've worked this out. The clue is from the debug info: With the ANSI UTF-8 setting, This doesn't occur in normal Scintilla since the bytes are treated as common European Latin code page 1252. However, Notepad++ has patched // Cyrillic / Turkish or other languages cannot be shown in ANSI mode.
// This fixes such problem. For more information about this fix, check:
// https://github.com/notepad-plus-plus/notepad-plus-plus/issues/5671
// case CharacterSet::Default: return documentCodePage ? documentCodePage : 1252;
case CharacterSet::Default: return documentCodePage;If the text is to be displayed as UTF-8, then the whole of Scintilla needs to know about that rather than just some platform layer functions. That way While it might be possible to have Scintilla detect this situation, Notepad++ should have a strategy for what it wants ANSI UTF-8 to mean. It could detect that The above-cited patch is troubling as it means that Scintilla may not correctly perform character set dependent operations like case-insensitive search when it is used to enable Cyrillic or Turkish. It would be better for Notepad++ to set an explicit character set like |
|
@nyamatongwe Thanks for digging into this. In the meantime I updated to Win11 and this issue still happens. As stated I changed the default code page, see e.g. : https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page I think I had no specific reason for that. Maybe some testing for python stuff. The visual effect is that textboxes are stretched:
What I find still strange is that release builds seems to have no issue with that. |
|
@donho At least some of the issues show |
I haven't seen that and don't have a theory for it. The length mismatch may lead to reading out-of-bounds uninitialized memory which can contain random values. However, the image appears systematic like its adding the width of the previous segment to the width of the current segment. Its unlikely to be worth chasing down as effort would be better applied to avoiding the situation. |
|
@chcg |
|
@MarkusBodensee There is no N++ release available which contains this update, so it can't be tested yet from normal users. |
|
@chcg Thank you for your explanation :) I just asked because most of the issues are closed when the pull request is merged. But waiting for user feedback after release is valid and good point. |
I understand that the specific problem in this thread is due to the system default code page being CP_UTF8 (something which was impossible when most of the relevant Notepad++ code was written). Don is working on it. As best I can tell, before the change in Scintilla which this patch reverts, a file encoded according to the system default code page, so long as that code page was a single byte character set, would display correctly in Scintilla by sending SCI_SETCODEPAGE(0). It appears this change in Scintilla broke that behavior on systems where Windows-1252 is not the system default code page. Scintilla documentation says single byte character sets should use SCI_SETCODEPAGE(0) and directs us to SCI_STYLESETCHARACTERSET. However, the suggested message sets individual styles, not the default for the whole document. Further, the relationship between character set values used in that message and the system default code page value from GetACP is unclear. What is the correct code to achieve the desired behavior (that is, for users with system default code pages that represent a single byte character set, no matter what that code page is, editing files in their system’s native encoding “just works”) without patching Scintilla? |
A reasonable generic approach is to set Scintilla to UTF-8 and convert from/to the code page to load/save. |
Release 5.5.5 (https://www.scintilla.org/scintilla555.zip)
Release 5.4.3 (https://www.scintilla.org/lexilla543.zip)