MoveLinesDown doesn't work on 2nd-last line

[jn64]

Description of the problem or steps to reproduce

MoveLinesDown (Alt+Down) does not work on the second-last line (tested at any column).

Nothing happens. It does not produce an error message like "Cannot move further down". It just fails silently.

Expected behaviour: MoveLinesDown on second-last line moves it down to the last line.

Specifications

Version: 2.0.4
Commit hash: c5b0c2d
OS: Linux (Fedora 32 Workstation)
Terminal: gnome-terminal

[jn64]

Hi @zyedidia, thanks for the quick response to this and #1723, however now there is new and different (unexpected?) behaviour. I will write in 1 issue since you are treating these together.

---

Below is the behaviour with new nightly ca976a8:

1. MoveLinesDown on 2nd last line will move the line down, but create a new blank last line. Repeating MoveLinesDown will keep creating new blank lines indefinitely.

2. MoveLinesUp on last line will move it up, but also create a new blank last line.

3. Undo is also broken in (2), as it will move the original last line back down, but not remove the new blank last line.

My expected behaviour for both of these operations is that the last 2 lines switch places and nothing else happens. Total number of lines and in fact filesize should stay the same. This would be consistent with similar operations at the top of the buffer (MoveLinesDown on the first line, and MoveLinesUp on 2nd line). I believe this is how most other text editors behave as well.

[zyedidia]

Yes I noticed this too. I'm not sure what the correct behavior is because technically the line being moved does have a newline at the end of it. Also all files should end with a newline (at least with eofnewline on which is default), and this is enforced whenever you save (I believe Posix text files should have a newline at the end to be valid).

Other editors don't always render the final newline with a blank line at the end like micro does, but I think it is helpful to do so to tell when files actually do not have that newline. For example, if I turn eofnewline off I can create a file without a newline at the end, and cat will display the lack of a newline, but in Vim the file displays the same as the version with a newline at the end. Adding a blank last line in Vim causes an additional newline to be added to the file (so the file will end in 2 newlines if one blank line is shown at the end of the buffer in Vim). Suffice to say I don't think you should be concerned about that final newline since it should be there anyway (even if it is not rendered by other editors it is still there).

[jn64]

I do like micro displaying the eof newline, so that is not a problem. I don't think it's relevant to both cases.

Case (1) is not related to (display of) eof newline at all. Creating new blank lines indefinitely is just weird. I don't know any editor, old or new, showing eof or not, that does this.

Case (2), I don't think micro is only displaying the trailing newline as you say. It's actually creating a new blank line.

Quick test with eofnewline disabled:

$ printf 'First line\nLast line' > testfile
$ cat testfile
First line
Last line$ # indeed cat shows the lack of trailing newline
$ ./micro -eofnewline false testfile # CursorEnd, MoveLinesUp, Save, Quit
$ cat testfile
Last line
First line
$ # now the file contains a trailing newline even though micro should not insert a newline

Even if there is an eof newline to be inserted, it should be done on save, not on the MoveLines operations. MoveLines should not add or remove a single byte from the file, only rearrange them.

[dmaluka]

There are also the following issues with MoveLinesUp at the last line (please see #1827):

• undo doesn't work correctly for it
• it modifies the buffer in readonly mode

[lslvr]

technically the line being moved does have a newline at the end of it.

Technically, yes. But what I would expect when moving a line is that, if the cursor reaches the line before the EOF, micro should stop me from further moving that line down; considering that the last line may be an empty line (just \n or \r\n) or a line which lacks a new line character.