Bug with the "CRLF" end of line
-
@guy038 said in Bug with the "CRLF" end of line:
Indeed, NO way to get the LF character at end of a line and the CR character at start of the next line, with the v8.7.9 release !
Clarification, please: You actually mean CR at the end of one line and LF at the end of next, don’t you?
-
Hello, @m-andre-z-eckenrode and All,
Yes, my bad ! Of course, I meant :
NO way to get the
CRcharacter at end of a line and theLFcharacter at start of the next line
BTW, @m-andre-z-eckenrode, are you able to reproduce ?
BR
guy038
-
Can you reproduce this weird bug ?
I can. in v8.8.1 (update: fresh unzip of portable, no extra plugins, etc) , if I follow your instructions (and resize the window-width and/or zoom), I can get it to wrap between the
CRandLF, and when I do, down-arrow from above gets “stuck” betweenCRandLF(though other arrows and page keys allow me to keep navigating to either side of the row of hyphens. I also checked in v8.7.9, and confirmed it will not let me change the width and/or zoom in such a way that it wraps between – it is always either both on the original line, or the final hyphen and theCRLFon the wrapped line, never in between.I can confirm, and would recommend creating an Issue about it.
-
@guy038 said in Bug with the "CRLF" end of line:
are you able to reproduce ?
As stated above, I could not reproduce what you describe in my fully-plugin-loaded installation of v8.8.0 (which is the 32-bit version, in case that matters). I have not tried with any portable/x64/plugin-disabled version. I’ll probably end up installing v8.8.1 32-bit later today (after completing the latest round of Windows updates), and will try to make a point of seeing if there’s any difference in behavior with it.
-
Hi, @m-andre-z-eckenrode, @peterjones and All,
I’ve just downloaded the
v8.8 - 32 bitsrelease and I do verify the bug, either !?Get stuck on line
24when going downwards !
Best Regards,
guy038
-
Based on what I observed in your screenshot, I opened a new NPP window, maximized it and changed my settings to UTF-8 and the Courier New font (I normally utilize a half-screen window size, ANSI text and the Georgia font), and retested your prescribed steps, and can now confirm the bug you describe under those conditions. Upon doing some basic process of elimination — encoding restored to my normal default of ANSI, but font and window state kept as same as what you appear to have used — your bug did NOT materialize, so I’d say that encoding is a factor.
-
@guy038 said in Bug with the "CRLF" end of line:
Can you reproduce this weird bug ?
I also can.
Seems to be a consequence of updating the Scintilla to v 5.5.6, relevant commit:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/5c1813185aa111d6247de39e3d7049ebef0960e0 -
Hi, @m-andre-z-eckenrode, @peterjones and All,
Ah… bravo, @m-andre-z-eckenrode ! You’ve found out the root of the problem. It’s indeed an encoding dependent bug !
I verified that all the options, below, produce that bug :
-
UTF-8 -
UTF-8-BOM -
UTF-16 BE BOM -
UTF-16 LE BOM -
Character Sets -
Convert to UTF-8 -
Convert to UTF-8-BOM -
Convert to UTF-16 BE BOM -
Convert to UTF-16 LE BOM
The two options, which work correctly and do NOT produce that bug, are :
-
ANSI -
Convert to ANSI
BTW, I generally used
UTF-8files, with theConsolasfont. So this bug does NOT seem to be font dependent !So, I will create an issue, regarding this bug, very soon !
Cheers,
guy038
-
-
-
So it really was a Scintilla v5.5.6 bug, fix for its next version:
https://sourceforge.net/p/scintilla/code/ci/0364bca4f6d3cb1e1aaffa3baae6a0dfe4b026f2/
