In Preferences -> Files there is an option "Ensure new line at file end" that, as far as I understand, is supposed to enable/disable adding of a new line in the end of the file if the last line is not empty. However, even when this option is disabled (unticked), if the last line is not empty and you save the file, Geany adds a new line after the last one.
I noticed that there is no new line at the end of the file if the option ```Ensure new line at file end``` is disabled and the file is closed. I checked that with a different editor (not with Geany). Only on re-opening the file in Geany the new line appears in the editor window - but it's not in the file. Not sure if that helps.
@Kzer-Za is it possible you're using a Project with `Ensure new line at file end` ticked in the Project Properties dialog?
This is a recorded message, please always provide the version of Geany, Glib and GTK (see lines near the top of Help->Debug Messages) and the operating system and version you are using.
WFM Geany 1.36 (git >= 4bceddb4), en_AU.UTF-8 GTK 3.22.30, GLib 2.56.4 Linux Mint,
- create new file add "foo", there is no return at end of line - ensure that the specified preference is unticked - save file - close file - open file, there is no return on end of file
Note if you add a return Geany will not remove it and as @codebrainz noted there is a project specific version of the option which overrides the general option.
@codebrainz, @elextr, thanks, I didn't know that this option was also in Project Properties and it overrode the one in "general" preferences.
Sorry about the insufficient information, usually I try to provide more detailed info, I guess I was getting sleepy. Anyways, the "issue" was with me not knowing about the project properties, so I guess I should close it now.
Closed #2310.
It's a common trap, see: #1363, #1611, #1881, etc.
@Kzer-Za is it possible you're using a Project with `Ensure new line at file end` ticked in the Project Properties dialog?
@codebrainz Thank you for pointing that out. That was my problem as well.
I noticed that there is no new line at the end of the file if the option `Ensure new line at file end` is disabled and the file is closed. I checked that with a different editor (not with Geany). Only on re-opening the file in Geany the new line appears in the editor window - but it's not in the file. Not sure if that helps.
I also had this issue wherein the geany editor shows there is a newline at the end of file but when I open the same file on vim editor, there is no newline. This leads to ambiguity and hence should be considered a geany editor bug in my opinion.
@iyernaveenr Geany will always show newline at the end of the file __if it exists in the file__, but will not show newline if it does not exist in the file, there is no ambiguity or bug.
But Vim does not show the newline at the end of the file it even if it exists, so this is ambiguous behaviour of Vim and a bug in Vim, feel free to open a bug on Vim.
@iyernaveenr Geany will always show newline at the end of the file **if it exists in the file**, but will not show newline if it does not exist in the file, there is no ambiguity or bug.
But Vim does not show the newline at the end of the file it even if it exists, so this is ambiguous behaviour of Vim and a bug in Vim, feel free to open a bug on Vim.
I tried with `cat -A <file>` as well to confirm. Issue seems to be with geany editor only.
I tried with cat -A <file> and other editors to confirm multiple times that the issue is with geany editor only.
You confirmed what with `cat -A`, show all your workings, I can't see over your shoulder.
I cannot replicate any bug in Geany, if I open a file with a newline at the end the extra empty line is shown, if I open a file with no newline at the end no extra line is shown. This is what is the intended behaviour, and as far as I can see Geany is behaving as intended.
You need to provide an exact set of steps that demonstrate your issue, if it can't be replicated it can't be fixed.
I guess the difference can be that Geany always shows newlines as such, showing an empty space after it: basically `\n` is allowing the cursor to be moved *after* it and appear at the start of the next line. There is no extra line; and a line without a trailing `\n` will not show that "extra line".
If `cat` does not break line after the last "line" (e.g. the prompt is concatenated on the same line) then Geany shouldn't show that newline, because there is none. But if `cat` shows the last line on its own (not an extra empty one!) this means there *is* a trailing `\n`, and then Geany will allow moving the cursor after that trailing `\n`. No bug here.
If you see otherwise, please give extra details explaining the details so we can reproduce.
Ahhh, philosophy, if the file ends in a newline is there an empty line (without a newline) (Geany) or is there a non-existent empty line if the file ends in newline (Vim), until that non-existent line gets some printable characters in which case it miraculously manifests, like if a tree falls in a forest ... you know the rest :grin:
I used two files (happened to be `filetypes.common`) identical except one had a `\n` at the end and one did not, `cat -A` showed the line end on the file where it exists (a `$`), and not on the other, Geany considers between the last newline and the eof to be the last line, irrespective of that being empty or containing characters. Vscode is the same, I don't have emacs (and don't care). Vim is different, thats its choice, but clearly many others have decided against (many of) its decisions, that does not make Geany/Vscode nor Vim "wrong", just different.
I tried with cat -A and other editors to confirm multiple times that the issue is with geany editor only.
You confirmed what with `cat -A`, show all your workings, I can't see over your shoulder.
I cannot replicate any bug in Geany, if I open a file with a newline at the end the extra empty line is shown, if I open a file with no newline at the end no extra line is shown. This is what is the intended behaviour, and as far as I can see Geany is behaving as intended.
You need to provide an exact set of steps that demonstrate your issue, if it can't be replicated it can't be fixed.
![issue_with_geany](https://github.com/user-attachments/assets/f1d97090-092c-42a3-9857-5e7186e71...)
Please find attached the screenshot which illustrates the issue, shows alternatives and provides details like machine info, geany version, etc. Also find attached a password-protected zip of that image just in case github has issues with images due to security or whatever reasons. Password to unzip is "geany1234" without the quotes.
[issue_with_geany.zip](https://github.com/user-attachments/files/17278715/issue_with_geany.zip)
Steps to replicate: 1) On Ubuntu 22.04.4 LTS x86_64, open the text editor that comes with Ubuntu and add the following lines (no newline at end of file): ``` int main () { return 0; } ``` Now, save this file as hello.c and exit.
2) Re-open file with the same editor and check if newline is added or not.
3) Open bash shell, type `cat -A hello.c` and check if it contains a '$' symbol immediately to the right of the closing brace '}' or in a newline.
4) Open hello.c with geany editor and check if it contains a '$' symbol immediately to the right of the closing brace '}' or in a newline.
If in steps 2) and 3) above, if you do NOT see a newline at the end of file, but you do see it in Step 4), then you know the issue is with geany only.
You could also try opening hello.c with vim editor to check the same. Note that I had this line in my .vimrc file: `set noeol`
Hope this helps.
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: ```shell $ 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
@iyernaveenr thank you for your better explanation.
It is not a bug, it shows Geany is behaving as it is intended, if the file ends with a `newline` character, Geany shows an empty line because thats what is after the `newline`, if the file does not end with a `newline` only the characters on the last line are shown.
Just to make sure you are understanding clearly, a `newline` is __a character in a file__ that specifies that the following characters are to be on a new line. A `newline` character can exist at any point in the file, including being the last character in the file. If a `newline` character exists at the end of the file Geany and Vscode show the empty new line as that `newline` character specifies. This is intended behaviour, it shows what the `newline` character in the file specifies ... a new line which has no characters on it.
There is no issue with Geany behaviour, it is as intended and is not a bug.
That Vim has some other behaviour is presumably Vim's decision. The fact that it does not indicate that there is a `newline` is what it decides, but it seems to me to be wrong and as @b4n said at least confusing. But that is Vim behaviour not Geany behaviour.
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
Thanks for your reply and your detailed explanation. The example you presented with the hexdump indeed makes the case in favour of geany editor. To better illustrate this for anyone reading, screenshot below shows @b4n 's example in different editors -
![geany_4](https://github.com/user-attachments/assets/2fe00fdc-1696-4e43-a47f-51c969128...)
Note that a.txt is the same as the hexdump @b4n presented and a_newline.txt, as the name implies, contains '\n' character after 'c'.
@iyernaveenr thank you for your better explanation.
It is not a bug, it shows Geany is behaving as it is intended, if the file ends with a `newline` character, Geany shows an empty line because thats what is after the `newline`, if the file does not end with a `newline` only the characters on the last line are shown.
Just to make sure you are understanding clearly, a `newline` is **a character in a file** that specifies that the following characters are to be on a new line. A `newline` character can exist at any point in the file, including being the last character in the file. If a `newline` character exists at the end of the file Geany and Vscode show the empty new line as that `newline` character specifies. This is intended behaviour, it shows what the `newline` character in the file specifies ... a new line which has no characters on it.
There is no issue with Geany behaviour, it is as intended and is not a bug.
That Vim has some other behaviour is presumably Vim's decision. The fact that it does not indicate that there is a `newline` is what it decides, but it seems to me to be wrong and as @b4n said at least confusing. But that is Vim behaviour not Geany behaviour.
Sure, thanks for your reply!
github-comments@lists.geany.org