> 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 -  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'. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/2310#issuecomment-2409018369 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/2310/[email protected]>
