> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/1810#issuecomment-373988136
