this is intentional: text files should always be terminated by \n, otherwise tools like 'cat', 'sed' etc may have problems. However there is no reason to always show an empty line at the bottom of the text view, that's why we do not show the last \n

i agree that text files should always be terminated by \n. however, there IS a reason to display them - because they are there! also, it's helpful to tell the user (eg. me) that there IS a terminating \n, but gedit displays no difference between the two.

also, what if you want to blank a file? you can't, because gedit puts an ending \n in. even if you chose to "patch this" by saying "oh if the last line is blank we'll delete it", what if the user wants the line to be there?

basically, this "feature" causes more problems than it fixes. there is no reason to accommodate for the special case when the file ends in a \n, by not displaying it.

just to note, geany adds an ending \n by default, but still displays them.

to clarify things to the end user, maybe instead of displaying the last line* as line {some number} you could display it as line "++" or something, to indicate that if you type here, a new line is going to be created.

*ie. the one that currently isn't being displayed

well, we displayed it for a long time and kept getting bugreports about that... we have to pick a side here and I don't think that a preference about this detail makes sense.

Also, every line is

foo\n
bar\n

so the \n is part of the last text line, the fact that GtkTextView shows a new line after each \n (causing the empty line at the end of the display) is just an implementation detail of Gtk.

> we displayed it for a long time and kept getting bugreports about that...
that's unfortunate, and strange... still, i've not come cross any other text editors which follow this behaviour. even GNU nano "displays" the last \n - as in, you can press [down] after the last line and get somewhere.

i think, the point of the last blank 'line' isn't to act as a "line of data" (like the other lines), but instead just as a "place to put more lines into", hence my suggestion about calling it "line++" above.

and surely
> is just an implementation detail of Gtk.
just means that you should leave this alone, instead of trying to "fix" it? :p

Well, I finally searched the web for this behavior and found this bugreport.

I assume this probably won't make any difference and I know the patch has been implemented for several years now. But I need to tell this anyhow.

First I need to tell about my (i.e. the user) way of working with gedit. Excuse me if I take the liberty to be a little bit elaborate.
I use gedit for a long time now and think it is a great texteditor with just the right features and still good performance. I use it for programming, taking notes, writing scripts, editing other source files or other things.
Of course as a long time computer and linux user I am totally aware of the mentioned newline character at the end of text files. I sometimes experienced the problems that can occur if this character is missing, too.
So I started to pay attention to this little detail when editing or creating textfiles a long time ago. I usually do this by hitting PGDN until I reach the end and see the cursor at the beginning of the last line. Sometimes there are even several more unneeded newlines at the end, then I trim them until it is exactly the way I want and need it to be.

Of course gedit is not the only texteditor I use. Sometimes I use mcedit (it even has the nice feature to make invisible characters visible), and sometimes other tools have to suffice, myself always keeping the newline character in my mind.

This is the way I worked for a long time.

Then suddenly I noticed several of my textfiles having an additional newline (i.e. two newlines) at the end. At first I was confused, but eventually found out that gedit now takes the liberty to add /another/ newline to the end of my files, whether there is already one (that means, I *see* it when the cursor moves to the beginning of the last line) or not.

Now every time I use a text editor I have to think: 'Does this editor add a newline?' and adapt my behavior accordingly. Still, everytime I hit PGDN or reach the end of my textfile and see the cursor stops at the end of the last line and won't continue to the last line, I wonder 'Uhm... something's missing... ah no, this is gedit, wait, it has to be this way.'

Do you start getting what I'm trying to tell?

Of course I understand and agree that textfiles should have a newline at the end. Of course theoretically it would be much easier if I just would not have to pay attention to this and the software takes care of it.
One could argue that I should now adapt my workflow to not thinking about newlines at the end anymore. But even then I would like to see what the editor does, i.e. may be able to move the cursor to this position.
But this again is not very intuitive and understandable either, and I totally understand that people submitted bugreports then.

Another thing are textfiles from /other/ sources. If I need to change a specific line, maybe only a character somewhere in the middle of a larger file, and hit CTRL+S in gedit, I really only want gedit to only change that single character and NOT also add a newline at the end if there wasn't one.
Can anyone be *really*, *really*, *really* sure, that there is not a single program out there that may perhaps work with textfiles where a missing newline at the end may be of some importance? What about textfiles with only one single line and not any newline character at all? Right now it is not possible with gedit to create or modify such a file and keeping it this way.

Please don't get me wrong, I really appreciate all the free work from the opensource developers and their motivation to always keep improving the software. But the behavior from gedit in this case is a) in no way transparent (the user should see and decide for himself if he wants a newline or not) and b) may modify files in a way that the user does not want and/or expect.

In my opinion the whole feature of automatically adding a newline should be reverted.

Thank you.