Columns++ display anomaly
-
I’ve apparently discovered a display anomaly which only occurs for me while editing an existing line that contains tabs, with the Columns++ Elastic Tabstops feature enabled, but it doesn’t happen for every line with tabs here. When I insert a character somewhere before a certain point near the end of the line (not sure what determines where that point is), the display jumps and an extra, pink line appears below the line I’m editing. While the pink line is there, I’m unable to use the down arrow to move the editing caret to the next line. If I switch to a different NPP tab and back, the pink line has disappeared and down arrow functionality has returned. See uploaded GIF animation.
For the record, I nearly always use a proportional font (Georgia, 10 point) and have my NPP window resized to occupy only the right half of my 1920 x 1080 display. The anomaly appears to only happen with lines whose lengths are roughly 75% or more of NPP’s window width.
Note, this is not the end of the world for me as it’s easy enough to work around. Just bringing it up because I haven’t seen it mentioned anywhere and wasn’t sure if you knew about it.
Uploaded: “2024-03-25 10;45;47 - MAZE - NPP Columns++ Elastic Tabstops.gif” (44,640) [740 x 53 x 8 x 255 frames]
-
That is certainly strange! Thank you for reporting it.
I haven’t seen this myself, but to attempt to recreate it I’ll need to know the version of Notepad++, what other plugins are installed, and their versions.
Would you post the information from ? | Debug Info… | Copy debug info into clipboard?
-
@Coises said in Columns++ display anomaly:
Would you post the information from ? | Debug Info… | Copy debug info into clipboard?
Notepad++ v8.6.4 (32-bit)
Build time : Feb 20 2024 - 00:11:10
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Command Line : “T:\Test.txt”
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 22H2
OS Build : 19045.4170
Current ANSI codepage : 1252
Plugins :
BetterMultiSelection (1.5)
ColumnsPlusPlus (1.0.2)
ColumnTools (1.4.5.1)
ComparePlus (1.1)
DSpellCheck (1.5)
ExtSettings (1.3.1)
HTMLTag_unicode (1.4.3)
mimeTools (3.1)
MultiClipboard (2.1)
MultiReplace (2.3.0.10)
NppCalc (1.5)
NppConverter (4.6)
NppExport (0.4)
NPPJSONViewer (2.0.7)
NppTextFX (1.4.1)
NppXmlTreeviewPlugin (2)
PreviewHTML (1.3.2)
PythonScript (2)
RegexTrainer (1.2)
SessionMgr (1.4.4) -
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.
