Swapping lines creates new empty lines

[korikhin]

If there is an empty line below the current line, swapping lines (using ⌥↓) creates new empty lines.

1 hello world  // cursor is here
2

Becomes (after pressing twice)

1
2
3 hello world  // cursor is here
4

Also:

1
2 hello world  // cursor is here

Press ⌥↑ and You get

1 hello world  // cursor is here
2
3 // new empty line created

[Andriamanitra]

The current behavior makes sense if you think of the newline characters as being part of the line ¹. If you think of the newline characters as separators between the lines ² it appears a new line is created. I can't think of an objective reason to prefer either way. Is there some use case where you would not want the "added" trailing newline?

Footnotes

1. "hello\nworld\n" => ["hello\n", "world\n"] ↩

2. "hello\nworld\n" => ["hello", "world", ""] ↩

[hholst80]

I think this is a bug. Moving line 2 up in a file with 2 lines should not end up with 3 lines no matter how you phrase it it is just not the expected result.

[Andriamanitra]

I think this is a bug. Moving line 2 up in a file with 2 lines should not end up with 3 lines no matter how you phrase it it is just not the expected result.

And it doesn't if you think of the newline character as part of the line: len(["A\n", "B"]) == len(["B\n", "A\n"]) == 2. I guess it's still a little bit surprising that the "B" gets a newline appended to it, but perhaps less so than if ["A\n", "B"] became ["BA\n"] after a swap.

I understand that the current behavior is unexpected (to some) but I'm not sure if there's an use case where it's undesirable.

[korikhin]

I get your point on considering \n as a part of the line, but we are humans, so it feels kinda counterintuitive. At least to my taste. This is the first time I see such a behaviour.

So if you want to have a new line at the very end of the file — just add it yourself after moving the text. That's why in (most) formatters having a trailing newline is an option.

As @hholst80 noticed, getting an "out of nowhere" new line is still an undesired thing in itself. I'd like to have control and don't want to be distracted by such a paper cut.

My point is that moving text should be bounded by the EOF by default and not push this boundary further. One could easily move some text lower than intended by accident and then deal with a bunch of empty lines after moving it back to the right place. This is the actual case. And furthermore, I use a buffer with history, so I don't always want to cut/paste since it bloats the history that I frequently search through (visually too).

Thanks!