php-mode should not set require-final-newline unconditionally #424
Description
Hi! I'm the author of an emacs customization called ethan-wspace which tries to be the definitive customizations for people who are obsessive about whitespace in their source code. The overall philosophy in my package is that if the file starts clean, keep it clean, but if it starts dirty, highlight the places where it's dirty so the user can preserve the dirtiness (to avoid making waves/increasing the size of a diff).
php-mode contains code such as this which sets require-final-newline unconditionally. This interferes with ethan-wspace because ethan-wspace would like to sometimes not include a final newline (again, to preserve the dirty state of the file). To ensure that a user knows that require-final-newline is incompatible with ethan-wspace, I have code that emits an annoying warning, which turns into bug reports (in this case, glasserc/ethan-wspace#33).
require-final-newline is a strange variable in the emacs ecosystem because after it was introduced, another variable, mode-require-final-newline, was introduced, which partially supplants it. Instead of users being responsible for setting require-final-newline in all the different modes where it is required, users can just set mode-require-final-newline, and modes that process text files are encouraged to set require-final-newline to this value. mode-require-final-newline defaults to t, and any major mode that inherits from prog-mode (including php-mode, which inherits from c-mode, which inherits from prog-mode) already sets require-final-newline to mode-require-final-newline (see http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/prog-mode.el#n253). In other words, although require-final-newline is a completely ordinary emacs variable that looks ripe for customization, generally any customization of it is wrong.
I understand that in PHP, there's a risk of newlines at EOF being rendered to the browser. However, #154 suggests that this is only a problem if multiple newlines are present at the end of the file. require-final-newline only adds a newline if the last character is not already a newline, so cannot contribute to this problem. (If it added a newline, there was already something after the ?>\n that would have been rendered to the browser.) As a result, I believe all uses of require-final-newline in php-mode can be deleted.
However, if this change seems too risky, a less drastic change might be to change the places where php-mode sets require-final-newline to t to instead set require-final-newline to mode-require-final-newline. Because users of ethan-wspace typically turn off mode-require-final-newline, this would still allow users of php-mode to use ethan-wspace without problems.