Bug with the "CRLF" end of line

guy038

Hello, All,

I’ve discovered a really strange bug regarding, at least, the two last releases !

Put this text in a new tab

This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
--------------------------------------------------------------------------------------------------------------------------
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example
This is an example

Move to this new tab :
Click on the Wrap around button or select the View > Word wrap option
Click on the Show All Characters button or select the View > Show Symbol > Show All Characters
If your default end of line is not CRLF, select the Edit > EOL conversion > Windows (CRLF) option
Increase the Zoom level, with the Ctrl + Numpad + shortcut, in order that the CR character is at the end of current line and the LF character is at the beginning of the next line. May be, it will be necessary to add few dashes to get this configuration !
Move to the end of document with the Ctrl + End shortcut
Now, move back to the beginning of the document with the Up arrow key => No trouble
Then, move down to the end of the document with the Down arrow key : this time your way is stopped at the end of the line of dashes !!!???

For instance, with the v8.7.6 release, there is no mean to get a CR char at the end of current line and the LF char ( of this same line), at the start of the next line !

I verified that, in Preferences > Editor2 > EOL (CRLF), it does not depend on the kind of EOL chosen : the problem is the same with EACH option !
I also verified that this bug does not exist if we use, either, the default LF or CR EOL !

Can you reproduce this weird bug ?

Best Regards,

guy038

M Andre Z Eckenrode

I’m unable to make it so that CR is at the end of one quasi-line and LF is at the beginning of the next. Tried getting there with both Zoom and adding dashes. I assume “last two releases” means v8.8.0 and v8.8.1. I’m still using v8.8.0, with a bunch of plugins. You’ve already verified the same thing happens if plugins are disabled?

guy038

Hello, @m-andre-z-eckenrode and All,

Well, my present releases 8.8.1 and 8.8.0 are, in fact, the versions 8.8.1_RC2 and 8.8.0_RC2, without any EXTRA plugin

Thus, I decided to download, successively, the npp.8.8.1.portable.x64.7z, npp.8.8.portable.x64.7z and npp.8.7.9.portable.x64.7z archives and repeat the test !

So :

I extracted the contents of the npp.8.8.1.portable.x64.7z archive in a test folder :
I launched Notepad++ v8.8.1
In Preferences... :
- I disabled the Enable session snapshot and periodic backup, in the Backup section
- I checked the custom color for EOL in the Editing 2 section
Then, I loaded my post about the CRLF bug

=> I was able to reproduce what I explained in my previous post :

Then I deleted all the files of this test folder
I extracted the contents of the npp.8.8.portable.x64.7z archive in the test folder
I re-ran the same process as above

=> Again, I was able to get the same behavior that the one described in my previous post :-((

I deleted all the files of that test folder
Finally, I extracted the contents of the npp.8.7.9.portable.x64.7z archive in the test folder
I re-ran the same process as before

=> This time, everything was OK. 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 !

Best Regards,

guy038

M Andre Z Eckenrode

@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?

guy038

Hello, @m-andre-z-eckenrode and All,

Yes, my bad ! Of course, I meant :

NO way to get the CR character at end of a line and the LF character at start of the next line

BTW, @m-andre-z-eckenrode, are you able to reproduce ?

BR

guy038

PeterJones

@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 CR and LF, and when I do, down-arrow from above gets “stuck” between CR and LF (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 the CRLF on the wrapped line, never in between.

I can confirm, and would recommend creating an Issue about it.

M Andre Z Eckenrode

@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.

guy038

Hi, @m-andre-z-eckenrode, @peterjones and All,

I’ve just downloaded the v8.8 - 32 bits release and I do verify the bug, either !?

Get stuck on line 24 when going downwards !

Best Regards,

guy038

M Andre Z Eckenrode

@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.

xomx

@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

guy038

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-8 files, with the Consolas font. So this bug does NOT seem to be font dependent !

So, I will create an issue, regarding this bug, very soon !

Cheers,

guy038

xomx

STR video:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/16373#issuecomment-2883743117