Notepad3: Bug (to be discussed): sorting might insert an additional line break

[engelhro]

Affected version

Released version v4.18.512.992

Steps to reproduce

1. Create an empty file.
2. Enter two lines, the first with text "b", the second with text "a".
3. Do not enter a line break after the second line (i.e., Notepad3 should only show two numbers with line numbers visible).
4. Use the "Sort Lines" function (ALT + O) with default parameters.

Note: the actual line ending style used doesn't matter here.

Expected result

The two lines are sorted, and the file still contains only two lines (no line break after the last line).

Actual result

The two lines are sorted, but now three line numbers are shown as an additional line break was inserted at the end of the last line.

Comments and other information

My „expected result“ is admittedly up to discussion. The line which ends up as the last one after sorting of course had a trailing new line already before, but on the other hand the line which was the last one prior to sorting (and ends up somewhere else) didn't have…

So somehow adding an additional line break during the sort operation seems counterintuitive, at least to me – it both changes the apparent number of lines and the actual character count (and file size). What do others think, is the current behavior the „correct“ (reasonable) one or the approach I have in mind?

If we agree on that second alternative, I'd like to propose an according change of the sort functionality.

[hpwamr]

Good finding @engelhro ! 👍
I agree with you, after sorting, a "normal" user does not expect a change in size and number of lines. 🤔

[RaiKoHoff]

Please test development beta "_X_MUI_4.18.608.1006"
I added an option to handle "zero-length" lines too.
(Keep in mind: "zero-length" lines are different to "empty lines", which consists of spaces/tabs)
Ed.: small Bugfix (selection after sorting): "_X_MUI_4.18.608.1007"

[hpwamr]

Hello @RaiKoHoff ,
Tested with Notepad3 (64-bit) X_MUI v4.18.608.1006
The issue invoked by of @engelhro seems to be resolved and the option to remove "zero-length" works too.

But I find a little regression with "zero-length" 😏

To be sorted

    ("empty line" or "zero-length")
a

Sorted with Release v.992

b
    ("zero-length")

Sorted with Release v.992

    ("empty line")
a
b

Sorted with beta v.1006

    ("empty line" and "zero-length")
a
b

In this case "empty line" and "zero-length", the sort of Release v.992* seems me correct.... 🤔

[RaiKoHoff]

Hi @hpwamr ,
v.992 removes all "zero-length" lines and add a "zero-length" line at the end (the origin of this issue).

New behavior: keep "zero-length" lines and handle them the same (regarding sort order ascending/descending) like empty lines (and don't add a "zero-length" line at the end.
(Regarding sort order: space/tab is before character)

[hpwamr]

A good point: a little bug in Stable v.992 (change of size by removing "zero-length" line(s) seems to corrected with the beta v.1006. 😃
To be sorted

1 b
2 ("zero-length")
3 ("zero-length")
4    ("empty line")
5 a
6 ("zero-length")
7 ("zero-length")
8    ("empty line")

Sorted with Release v.992

1    ("empty line")
2    ("empty line")
3 a
4 b
5  ("zero-length")

Sorted with beta v.1006

1 ("zero-length")
2 ("zero-length")
3 ("zero-length")
4 ("zero-length")
5     ("empty line")
6     ("empty line")
7 a
8 b

Result expected

1    ("empty line")
2    ("empty line")
3 a
4 b
5  ("zero-length")
6  ("zero-length")
7  ("zero-length")
8  ("zero-length")

My "expected result" is certainly open to discussion. 🤔 😃

[hpwamr]

(Regarding sort order: space/tab is before character)

I think, it seems more expected:

• space/tab is before character
• but "zero-length" is after character

My "expected sorting" is certainly open to discussion. 🤔 😃

[RaiKoHoff]

My opinion is:
"I can't see the difference (except I use "show white-spaces"), so why using different ordering?"

Okay, lets wait for other opinions...

[engelhro]

I can confirm (tested with beta 4.18.608.1007) that my original issue has indeed been resolved :+1: (I'll close the issue after the next release, especially with the additional discussion going on right now).

My opinion is:
"I can't see the difference (except I use "show white-spaces"), so why using different ordering?"

I have no strong opinion regarding the sort order for "empty" vs. "zero length" lines (as long as they do not get mixed!). But independent of that, the argument "they look the same" seems weird to me (I know we already discussed this in the past with an issue regarding merging or removing apparently empty lines) – such lines are definitely different and should be treated accordingly.

As such I can see the charm of sorting "empty lines" (with content, even if only various whitespace combinations!) before any other text, and actually really empty (i.e., "zero length") lines as separate block after any other text. This makes their different character clear even without "show whitespace" being toggled on.

But that's a personal preference, not something I'd insist on.

[hpwamr]

As such I can see the charm of sorting "empty lines" (with content, even if only various whitespace combinations!) before any other text, and actually really empty (i.e., "zero length") lines as separate block after any other text. This makes their different character clear even without "show whitespace" being toggled on.

But that's a personal preference, not something I'd insist on.

Same for me. 😃
I thing that my personal preference is certainly influenced by the _"sorting scheme of Excel"_ ? 🤔

• cell with "space" is before character cell
• cell "zero-length" is after character cell

Hello @RaiKoHoff, I will accept your final decision. 😏

[RaiKoHoff]

With development beta version "_X_MUI_4.18.611.1008", you are able to distinguish between "empty = zero-length" lines and "white-space only" lines for removing.
As a second change, white-space are handled according to sort order (ascending/descending), empty (zero-length) lines are moved (if not removed) to the end, regardless of sort order. Following the argument of @engelhro and @hpwamr .
A third change is: option "Remove empty lines" is checked by default (as it was before, when it was not switchable).
If that is fine, we can close this issue.

[hpwamr]

Tested with "Notepad3 (64-bit) X_MUI v4.18.611.1008".
Only one word: "Wonderful" ! 👍 ❤️
As far as I am concerned, this issue may be closed....

[engelhro]

Just tested beta v4.18.611.1008. Indeed, that's a fine solution :+1:. I like the new options for both sorting and removing empty and/or zero length lines.

There's one last quirk: the "merge duplicates" doesn't consider empty and zero length lines – is this intended? In my opinion this option should also cause several zero length lines being merged into just one, and the same applies to several empty lines (with the same whitespace pattern of course, otherwise they'd be different by definition).

Please note that I'll be away for a two and half weeks now, so further tests and the closing of this issue (which I'd postpone until after the next release anyway) will not happen before early July…

Happy NP3ing!

[RaiKoHoff]

Beta version v4.18.611.1008 merges duplicate white-space-only lines correctly.
Only empty lines ("zero-length lines") are not merged. I will fix this.

[RaiKoHoff]

Above problem should have been fixed with one of the beta builds of last 1.5 months ...

[engelhro]

Confirmed, everything works now :+1:. I'll close the issue.