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)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.