"Join Lines" with trailing whitespace anomaly, older npp versions
-
Hello.
A macro I considered reliable yielded some unexpected output which led me to investigate, and to my surprise the anomaly was traced to the Join Lines operation.
To produce the unexpected result start with 3 consecutive lines where:
- 1st line has 1 or more trailing spaces
- 2nd line is empty (nothing but CR/LF)
- 3rd line has some text.
this line has a trailing space followed by an empty line just a normal lineNow make a selection that starts anywhere on line 1 and ends anywhere on line 3 beyond column 1. Issue “Join Lines” by menu or shortcut.
Expected is all the text from the 3 lines is on a single line (ofc ending in CR/LF).
Observed is 2 lines; the 1st contains original line 1 text but it ends in a single CR – the LF was dropped! ; the 2nd is identical to the original line 3.
This behavior occurs in versions v8.1.9 (32-bit, portable) and v8.4.5 (32-bit, portable) but the expected, correct behavior occurs with v8.7.5 (64-bit, installed).
In all cases, Windows (CR LF), UTF-8.
I searched for discussion of this issue both here and on Github but failed to find any mention of it. I do consider it pretty unlikely that I’m the first to encounter this problem since it’s such a basic function operating under not terribly unusual conditions. And the misbehavior would likely have existed over a non-trivial time span. So I’m curious if anyone has familiarity with it, and anyway, in the off chance this is a new discovery, at least someone who has a strong need to stay with an old version might find this post in a search and be better positioned to decide how to proceed.
-
Hello, @neil-schipper, and All,
I can confirm that the
Edit >Line Operations > Join Lines(Ctrl + J) works correctly in portablex64N++ versions8.6.2/8.7.6and the last8.8.3release.I tried to see what has changed between the
8.4.6and thev8.6.1releases, in order to get the correct behavior, from the link below, though without any pertinent result :https://github.com/notepad-plus-plus/notepad-plus-plus/wiki/Changes#8x
Best Regards,
guy038
-
Hi @guy038,
Thanks. That “Changes” page you linked spans 4 years of development and the word “join” doesn’t appear once!
I wouldn’t be surprised if the code underwent “self-healing” when a developer decided to use a more advanced (= lots of built-in safety, lots of tests) buffer object / library which allowed a bunch of hand-crafted string handling code (maybe duplicated in a bunch of places) to be factored out.
And I smile when I write this because of a comedic article I once read where the guy explains that when a warning light he’s never seen before comes on on his car’s dashboard, his natural response is to… ignore it for a bunch of months to see if the process of “automotive self-healing” kicks in!
-
It was a Scintilla bug; see:
-
@Coises said in "Join Lines" with trailing whitespace anomaly, older npp versions:
It was a Scintilla bug; see:
… which was fixed in scintilla 5.3.3 (per https://scintilla.org/ScintillaHistory.html at 5.3.3)
And so
thatupdating to 5.3.3 was mentioned in Changes for v8.5 item 3.Unfortunately, it is not feasible for N++ changelist to list every change for a given scintilla upgrade, so it makes it harder to find such things.
-
Thanks for the closure, guys.
I noticed at the github page Coises linked, item 2, the bug link erroneously goes to an unrelated bug page, due I suppose either to human error or an artifact of github’s automagically linking text of form #nnnn to an assumed github target.
I also noticed at the scintilla history page Peter linked that the most recent mention of a join issue prior to the Feb 2023 fix is from March 2007. 16 years x millions of daily users… that’s a lot of joins, and if between a millionth and a thousandth of all those joins operated on text meeting the bug’s precondition, that’s a lot of files picking up malformed line endings (in addition to visibly incomplete joins). Seems crazy the bug persisted as long as it seems to have.
-
@Neil-Schipper said:
I noticed at the github page Coises linked, item 2, the bug link erroneously goes to an unrelated bug page, due I suppose either to human error or an artifact of github’s automagically linking text of form #nnnn to an assumed github target.
It was caused by “an artifact of github’s automagically linking text of form #nnnn to an assumed github target.”
Which could then lead to a conclusion of “human error”, because if you put
#2372in your commit message, you should realize that github is going to perform that magic on it… -
@Alan-Kilborn True enough.
I couldn’t see a way to edit the commit msg (full-on verboten? requires special privilege?) or even leave a comment, so I invite a keener to fix it as the task is beyond my weight class.
