Coloured Strip / Unselectable

[meteorquake]

This is the second time in a few days I've got a magenta strip (attached) in a .bas document, but possibly can happen in any format. It seems to be the same colour as the code numeric (see eg 0 in the screenshot) and also the named label. I've not spotted how to make it repeatable yet but thought I would flag it up for awareness. I'll comment when I have further insights. I'll try to change the syntax colouring so its origins are less ambiguous [ed: Now done: it appears to come from the numerics]. I'm also finding issues where sections of line are not selectable presumably due to the screen not reflecting the underlying representation. Both disappear on doing zoom-in-out action. They appear unpredictably on scrolling.

Notepad2 (64-bit) 4.22.09 r4360 (1c611395) Compiled on Sep 18 2022 with Visual C++ 19.33.31630.0, Scintilla 5.3.0. Encoding: UTF-8, Windows-1252 Scheme: .bas, Visual Basic System: 10.0.19044 x64

David

[meteorquake]

It's just done it again at a different spot but I had changed the label colour so it appears to come from the numerics.

[zufuliu]

The purple color come from https://sourceforge.net/p/scintilla/code/ci/e110bf1a93eb1af46621bc6cfb4bf91db1056e9b/

https://github.com/zufuliu/notepad2/blob/3d0b8f81378f2f7ad51ede47f2101cba261895af/scintilla/src/EditView.cxx#L1926-L1931

So there are bugs somewhere (see https://sourceforge.net/p/scintilla/bugs/2349/?page=1).

[meteorquake]

Aha thank you. Well that explains the appearance, we'll have to hope the underlying cause gets spotted... Cheers, David

[zufuliu]

The purple background is disabled in 1f7d69285216543356d0cb620852fa25ba2d248d, you can download the latest build from https://github.com/zufuliu/notepad2/actions to make life easy.

It's better if there is a reproducer (and steps to reproduce the bug in Notepad2) as the linked Scintilla bug is for GTK based Geany (https://github.com/geany/geany), and fixes goes into GTK related code.

[meteorquake]

What seems to be the case for mine, is (I surmise) there must be two slightly non-identical calculators in operation for how much space a paragraph takes up; one for the line in question when it is rendered, another for general layout planning. In wrapped mode, the render action can end with the final word at the end of a line but the general layout planner has considered it would wrap onto the next and when that doesn't happen a magenta strip is displayed. Similarly, the renderer may decide to wrap the final word onto the next line but the general layout planner considered it would have fitted at the end of the previous line and did not allow a line for the overwrapping word, causing a missing line (of one word) when the rendering is constrained by what was allocated by the layout planner. When for example you have a rendering that ends at the right edge of the screen followed by a magenta strip below and you do zoom in-out, that end word then appears not at the end but on the next line where the magenta was, and the magenta is not displayed. d

[meteorquake]

One additional bit is that I always use the proportional font Trebuchet MS for everything. It may, for example, be that the issue doesn't occur with monospaced fonts. Equally perhaps it's caused by a tiny or subpixel miscalculations of the text area (e.g. calculating the scrollbar or right margin, or where the edge of anti-aliased text actually occurs, or pixel fractions aggregating to a whole pixel). It is interesting that the matter is cleared by zooming in and out: presumably some globally-retained part of the layout calculation can get and accumulate errors or rounding/subpixel errors, or simply isn't reset when it should be, and it becomes helpfully cleared by the zoom... well I can only hope someone spots it :) d