<blockquote>
<p>I'm actually just trying to look at some open-issues</p>
</blockquote>
<p>Yes, noticed and thank you for your efforts (we don't say that enough).</p>
<p>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.</p>
<p>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.</p>
<p>Real bugs should be checked from time to time to see if they are still relevant or fixed or just bit rotten.</p>
<p>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?</p>
<p>Anyhow, philosophy lecture over, back to this PR, technically POSIX requires the <code>\n</code> at end of file, a line <strong>ends</strong> 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.</p>
<p>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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/1810#issuecomment-373988136">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ9xJdkVNRxVnxfGm-2s7Z4rMOCIwks5tfjqbgaJpZM4SuypE">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABDrJ1vERCSED_Nb_rAZeghelhqBV0F2ks5tfjqbgaJpZM4SuypE.gif" height="1" width="1" alt="" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/1810#issuecomment-373988136"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@elextr in #1810: \u003e I'm actually just trying to look at some open-issues\r\n\r\nYes, noticed and thank you for your efforts (we don't say that enough).\r\n\r\nAs 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.\r\n\r\nBut 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.\r\n\r\nReal bugs should be checked from time to time to see if they are still relevant or fixed or just bit rotten.\r\n\r\nOne 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?\r\n\r\nAnyhow, 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.\r\n\r\nSo 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."}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1810#issuecomment-373988136"}}}</script>