Columns++ display anomaly
-
Thank you for the information. I was hoping that if I installed your version of Notepad++ and the same set of plugins, and set the same font, perhaps I would see the same result. No such luck.
Is this a plain text file, or something else? (That is, is the file being displayed using the Global styles, or a language?)
Can you think of anything other than this unexpected empty line that appears in that color (looks like magenta, 0xFF00FF) when you use Notepad++? I’m trying to get any possible lead on what is triggering it.
Is it always when editing the first line of a file that this happens? I ask because the implementation of elastic tabstops in Columns++ displays some odd, “jumpy” behavior when changing the width of a column only when editing the first line. I’ve never been able to figure out why, but if what you’re describing also happens only when editing the first line, the two phenomena may be related.
-
Plain text, Global Styles, Default theme. I looked through all the colors used in the various style settings for Global Styles. A few use purple (deeper/darker than the color I called pink and which you refer to as magenta, which I concede is more accurate), but none are the same as what this anomaly results in.
In the case of the (gibberish) text I used to create the animated GIF you see displayed above, that was the only text/line at all in that editing tab, but I previously encountered the anomaly while editing an other-than-first line, with non-empty lines both above and below it, in a fairly small plain text file, a few K at the most.
-
@Coises said in Columns++ display anomaly:
Can you think of anything other than this unexpected empty line that appears in that color (looks like magenta, 0xFF00FF) when you use Notepad++? I’m trying to get any possible lead on what is triggering it.
It seems like Scintilla is causing the highlight to occur by detecting a line with an empty wrapping.
View the comment of Scintilla bug #2349 some lines appear twice which has an image that looks similar to the OP image.
It was committed with the message:
When more screen lines in ContractionState than LineLayout for a line then draw extra lines in purple bugColour to make the problem obvious.
The bug colouring still exists in the source .
-
@mpheath said in Columns++ display anomaly:
View the comment of Scintilla bug #2349 some lines appear twice which has an image that looks similar to the OP image.
Thank you!!!
If I’m reading that right (and I will have to read it again tomorrow), it sounds like there was (and perhaps still is) a rare Scintilla bug, and this was put in the code to make it obvious when it happened.
Whether the original poster’s circumstance is triggering the bug, or triggering an as-yet-unknown Columns++ bug that causes it to call Scintilla with bad data that causes this signal flare to be sent up, remains to be seen.
-
Thank you for your patience.
By accident, I managed to get that magenta line to flash. Though the details in my case are different than yours, I think I can now reproduce it at will. Since I couldn’t get it to happen by trying to copy your example, I’m guessing there is something very system-specific about it.
Combined with @mpheath’s observation, I can hopefully get to the bottom of this.
I presume this only happens when View | Word wrap is checked? When it happens, does dragging either the left or right side of the Notepad++ window just the tiniest bit wider or narrower make it go away?
-
@Coises said in Columns++ display anomaly:
I presume this only happens when View | Word wrap is checked? When it happens, does dragging either the left or right side of the Notepad++ window just the tiniest bit wider or narrower make it go away?
Looks like yes on both counts.
-
I think Columns++ version 1.0.6 will resolve this issue.
When you have the opportunity, please let me know if this fixes it, or if you still see a problem.
Thank you for your patience.
-
So far, so good — I’m unable to replicate the anomaly under same as previous circumstances. Thanks! Will let you know if it rears its ugly head again and I have any reason to think Columns++ is involved.
-
Out of interest, getting similar behaviour in a UDL when selecting Arial as font as opposed to Consolas:
<WordsStyle name="COMMENTS" fgColor="008000" bgColor="000000" colorStyle="1" fontName="Arial" fontStyle="2" nesting="0" />As before type a long line of text which overflows the wrap limit thus
texttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttext
Then insert before it the opening comment tag:
/*
Solid pink line appears below the long line which prevents any cursor movement below with down-arrow.
Replacing Arial with Consolas for example doesn’t repro.
Some rare irreproducible glitchiness with pink lines may occur in other situations by just typing the slash instead of the asterisk.Edit: Just realised this is for a plugin not installed - the issue seems to be with N++ itself. Sorry.
-
@Laurie-Stearn said in Columns++ display anomaly:
Out of interest, getting similar behaviour in a UDL when selecting Arial as font as opposed to Consolas:
<WordsStyle name="COMMENTS" fgColor="008000" bgColor="000000" colorStyle="1" fontName="Arial" fontStyle="2" nesting="0" />As before type a long line of text which overflows the wrap limit thus
texttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttext
Then insert before it the opening comment tag:
/*
Solid pink line appears below the long line which prevents any cursor movement below with down-arrow.
Replacing Arial with Consolas for example doesn’t repro.
Some rare irreproducible glitchiness with pink lines may occur in other situations by just typing the slash instead of the asterisk.Edit: Just realised this is for a plugin not installed - the issue seems to be with N++ itself. Sorry.
When it happened with my plugin (Columns++) the cause turned out to be a wrapped line getting shorter (due to tab layout changing), so that it needed one less wraps. The solution involved temporarily disabling Scintilla’s line cache: something that can cause slow processing in large files with word wrap on. The problem doesn’t happen when editing itself makes the line shorter; it happens when something done after the editing is complete (like recalculating tab widths, or changing styles) causes the line to get shorter.
My guess is that in this case, the text wraps to n lines after editing, before the new styling is applied; then, when styling is applied, the text only requires n-1 lines for wrapping, and the leftover line is magenta-marked. That marking is a Scintilla “feature” to show that something went wrong. (Why it doesn’t just correct the wrapping instead, I don’t know. Scintilla is open source, but it’s still pretty much a black box to me.)
The practical fix is probably to avoid specifying different fonts (or font variations with differing widths) for different styles if you expect to use them with word wrap. For performance reasons, turning off the Scintilla line-wrapping cache would not be something Notepad++ would do.
