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.

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 **new**line, 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)