All you say sound right but the fact there is an issue. Well, do you actually have an issue in the first place? What we're talking about is merely a different way of displaying the same data. Or does opening and saving a file in Geany change how e.g. Vim shows it?
I guess the best thing you can do to see what we're talking about is showing line endings in Geany: you'll see that "line 5" does NOT have an EOL, because it's merely what's after the EOL of "line 4"

Again, this is all about how to represent the last line: Geany will show a line 5 because there's an EOL at the end of line 4, so the cursor can actually go beyond it. Some other tools don't show anything unless you start adding stuff after line 4's EOL.
Basically, Geany tries and makes it natural to add a line without an EOL: it considers "lines" being stuff separated by EOLs. Some other tools consider lines as stuff ending with EOL, but that doesn't play super nice with a last line without an EOL.
I had a hard time getting Vim to not add or remove the EOL, as it's not as trivial as :set noeol, but managed it after some research. Yet, when opening a non-EOL file, it does not show it any differently than if it has one if not for the [noeol] mark in the statusbar -- and by default it seems to add the EOL back to "fix" the file.

Now, such a file without a trailing EOL, cat will not show what you have in your screenshot:

$ hexdump -c /tmp/a.txt
0000000   a  \n   b  \n   c                                            
0000005
$ cat /tmp/a.txt
a
b
c$ # this is the prompt, because there was no extra \n to move it to the next line
$ cat -A /tmp/a.txt
a$
b$
c$ # and this is the prompt again, and now it's confusing because it's rendered as `$` just as cat's EOLs

With this file, Geany will show only 3 lines, because the last one doesn't has an EOL.

IMO, this all sounds like a big confusion and there is no actual behavioral problem. And as to whether or not showing an "extra" line at the end is good or bad, I'd say that:

it makes supporting non-EOL files a lot less confusing or at least more coherent
it's most likely never an actual issue: if you really care whether there's an EOL, display those so you're sure

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.