Nothing more to say. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1810
-- Commit Summary --
* document: do not add a new-line to an empty file. Fixes #1539.
-- File Changes --
M src/document.c (7)
-- Patch Links --
https://github.com/geany/geany/pull/1810.patch https://github.com/geany/geany/pull/1810.diff
One thing to say:
This appears to break "Ensure newline at file end" for otherwise empty documents. :(
Yes, well if you read #1539 that was exactly the problem. The option "Ensure newline at file end" prevents empty files.
So we need to decide what's more important: - do we need to ensure a newline for an otherwise empty file - do we need to be able to create really empty files (0 byte size)
Both things are IMHO not very important. Let's make up a decision. If this is not merged then maybe also #1539 should be closed as "wontfix".
Options should be simple consistent and not have lots of special cases attached (a rule Geany doesn't always follow and that causes confusion in many cases). So if the option says it ensures newline at EOF then thats what it should do. Yes that means you can't use Geany to create empty files, but if you add the exception then you can't use Geany to create files with one newline.
Its not as if there are not existing methods of creating truly empty files, `touch` being the canonical one, and my desktop's file manager also offers to create empty files if you are command line challenged. But external means for creating files with a newline are less obvious (`cat` and so on).
Another way of looking at is that Geany is primarily an editor, if you are not going to edit the file (its intended to be empty) why open it in Geany?
So personally I'd make it "won't fix" except we don't have that label (__yet__, I have been itching to make one though :).
Yes that means you can't use Geany to create empty files,
unless you uncheck the option of course :)
unless you uncheck the option of course :)
Yes, it's really just a comfortability issue and I'm totally fine if the PR would be rejected and having the issue closed as "won't fix" (or some other label which is appropriate). I'm actually just trying to look at some open-issues which I can fix myself to get Geany a bit away from the 500 open-issues border :innocent:
I'm actually just trying to look at some open-issues
Yes, noticed and thank you for your efforts (we don't say that enough).
As is illustrated by the lack of a "won't fix" label Geany tends to not have much of a hard reject philosophy, especially for enhancements. In general if someone thinks something is important enough to make a PR then thats where real objections are raised, when there is something concrete to criticise.
But many of the older enhancement issues simply nobody who is capable of doing them thinks they are worth doing, so they sit. Probably we need a policy on how old enhancement requests get before they are marked "archived" and closed.
Real bugs should be checked from time to time to see if they are still relevant or fixed or just bit rotten.
One other issue is enhancements that are written as bugs, we don't always agree whats a bug, if Geany doesn't do something, and its not intended to do it, like edit files across the network by URL, is that a bug or enhancement?
Anyhow, philosophy lecture over, back to this PR, technically POSIX requires the `\n` at end of file, a line __ends__ in newline, including the last one, and the C standard requires a warning if its not there and is likely the main reason for the Geany option (hopefully thats gone away in newer than C99, but I didn't check), but practically in most cases applications don't care. But there are still a few places where it matters, for example file catenation, and as I said its technically required in POSIX systems so technically all files Geany writes should end in newline as they are all text files.
So lets wait for a week, but unless somebody has a really good case to keep it, I would say skip this PR and mark the original issue invalid (closest to "won't fix") and close it.
I agree :+1:
I agree too, would rather close #1539 as wontfix. Thanks for bringing this to our attention and for your efforts on visiting old bug reports!
Yes that means you can't use Geany to create empty files, but if you add the exception then you can't use Geany to create files with one newline.
I don't think that's right: if you manually enter one newline, Geany will keep it, so you'd just have to insert the newline manually.
However, I really don't feel strong about that. I understand it can be nice in some corner situations to be able to save a totally empty file (e.g. removing all content to get a truly empty file); but also agree with @elextr that adding special cases to features makes them more complex to follow (imagine the next issue: "Geany doesn't insert a newline in an empty file even when 'insert newline at end of file' is checked" :grin:). So… whatever you guys think is fine, as you seem to feel more strongly about this.
Then let's close this and #1539 as wontfix.
Will leave for the rest of the promised week, but that seems the consensus.
Closed #1810.
Closing as per consensus
Hi, I was looking for this, as I often read log files, and sometimes I's like to truncate them. Other than this, I like adding new line to the end of files, but when I truncate a log file, it stays an empty line, so next write goes always to second line. At least, if it's not too hard, it would be awesome to have a switch for this under the newline checkbox.
Anyway, Geany is my favourite editor long ago, thanks for creating it.
github-comments@lists.geany.org