Blank extra line displayed for files with terminating newline

[JShorthouse]

If I open a newline terminated file in geany extra blank line is displayed:

This is incorrect according to the POSIX specification of a file, in which all lines should be newline terminated. From looking at how geany presents the file it would appear that the file has 6 lines with the final line being empty, when it actually only has 5 newline terminated lines.

wc correctly reports only 5 lines in this file:

And vim correctly only displays 5 lines:

[elextr]

The behaviour of Geany is self consistent, if you move the cursor after the newline it goes to the start of the next line. That means you need to have a visual next line after the last line for it to go to.

Also, irrespective of what POSIX says there are situations where files must not have a terminating newline (inline includes for example) so there needs to be a way of indicating the presence or absence of the last newline. But its impossible for a mere editor to know if its a file with a terminating newline, or a file with an empty unterminated last line, so it shows the presence of a newline by showing a next line place for the cursor to go.

This is the behaviour of other proper modeless visual editors/IDEs, Mint Text Edit (a Gedit clone IIRC) and Eclipse being the two I have at hand and a quick peruse of the vscode docs suggests its the same.

[JShorthouse]

I understand that this is a subjective issue, so perhaps it could be a configuration option (like automatically adding a terminating newline on save is)?

I think there are valid arguments for either side. I know there are many other IDEs that behave the same was as Geany currently does, but in my personal opinion they behave incorrectly.

Early text editors such as Vim and Emac displayed files with lines according to POSIX. It was the newer IDEs that decided to come along and break this long standing convention, and thereby causing all of this confusion. If they had just stuck to the POSIX-correct interpretation of newlines as Vim and Emacs do then I think there would be no confusion and debate around terminating newlines.

The behaviour of Geany is self consistent, if you move the cursor after the newline it goes to the start of the next line.

I'd argue this isn't consistent at all because the last "line" isn't a line at all (according to POSIX). Trying to move the cursor past the last line with text shouldn't go anywhere.

vscode

You are correct that vscode behaves the same way as geany by default, but it also has a configuration option to hide the last line (editor.renderFinalNewline).

In summary I can understand why people would want the editor to show lines this way, but there are also many people who don't. As previously explained the current behaviour is inconsistent with basically all long-standing unix tools, from inspecting a file with vim or wc -l is appears that geany is adding blank lines. The default behaviour can be kept but I would very much appreciate an option to hide the final line if possible.

[elextr]

A quick google didn't find any option to hide it in the Scintilla editing widget (which is what draws that line) so unless I missed it the option would have to be added to that project first then a pull request could be made to add setting the option in Geany.

[cousteaulecommandant]

I'd argue this isn't consistent at all because the last "line" isn't a line at all (according to POSIX). Trying to move the cursor past the last line with text shouldn't go anywhere.

It is self-consistent, i.e., consistent with the rest of Geany's behavior, not consistent with POSIX.
Specifically, Geany will display an empty line at the end of a file if the file is newline-terminated, and not do it if it's not, so the user can tell the two cases apart.
This is not the case for Gedit, for example, which will happily open newline-terminated files and non-newline-terminated files, treating the latter exactly as the former, so you can never tell if the file was actually newline-terminated. (A more "correct" behavior for POSIX compliance would be to refuse to open those files, but that would just be an unnecessary obstacle.)

This is all a matter of whether you consider a text file as a sequence of newline-terminated lines or newline-separated lines. POSIX requires the former, but not everything is POSIX. For example, C has this requirement, C++11 doesn't, Git and diff don't but display an ugly note in the output, and some weird formats (arguably not 100% able to be considered as "text files") may stop working if you add a newline at the end, but are otherwise perfectly viewable and editable with Geany.
(Also, notice that it's called newline, so it kind of hints that a new line comes after it :) although this is probably a poor argument.)

A possible compromise solution would be to display the last line with a +, \, or end as the line number, indicating that it's "not a real line"; that way it's technically not "line n", but "weird thing at the end", or "start typing here to add a new line to the file"; that way you don't have to hide it, but don't have to count it as a line either:

1 int main(void) {
2     return 0;
3 }
+
 

(the tricky part is that the status bar would have to report "line: 4 / 3" or "line: end / 3" if you wanted that indicator to be POSIX-compliant, but I guess that can be done)