New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document: do not add a new-line to an empty file. Fixes #1539. #1810
Conversation
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:
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, 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 :). |
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 😇 |
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 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 👍 |
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! |
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" 😁). |
Then let's close this and #1539 as wontfix. |
Will leave for the rest of the promised week, but that seems the consensus. |
Closing as per consensus |
Hi, Anyway, Geany is my favourite editor long ago, thanks for creating it. |
Nothing more to say.