bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Ethan Glasser-Camp]

I am the maintainer of a package called emacs-wspace, available at
github at https://github.com/glasserc/ethan-wspace/. The goal of the
package is to help keep whitespace in files clean without introducing
spurious whitespace changes. In order to do this, the package requires
users to turn off require-final-newline and sometimes
mode-require-final-newline. If ethan-wspace discovers that
require-final-newline is set to t, it admonishes the user.

One user reported that ruby-mode triggers this warning. Sure enough, in
ruby-mode.el at line 287, I see:

  (set (make-local-variable 'require-final-newline) t)

There is some precedent for doing this sort of thing with the variable
mode-require-final-newline. Is it possible for ruby-mode to respect this
variable?

More discussion can be found at this bug report for cucumber.el, another
mode which seems to borrow the pattern from ruby-mode:

https://github.com/michaelklishin/cucumber.el/pull/51

Thank you for your time.

Ethan


In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-07 on lamiak, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x <help-echo> <down-mouse-1> <mouse-1> C-x o r e 
p o <tab> r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-mode easymenu time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Eli Zaretskii]

> From: Ethan Glasser-Camp <ethan.glasser.camp@gmail.com>
> Date: Sat, 05 Jul 2014 14:07:16 -0400
> 
> If ethan-wspace discovers that require-final-newline is set to t, it
> admonishes the user.

Why does ethan-wspace need to admonish users for setting
require-final-newline?  Can this be avoided?

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Ethan]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

The idea behind the package is that bad whitespace is highlighted, not
automatically cleaned up. So if the file doesn't have a final newline when
it is first loaded, no final newline will be added without explicit user
action -- instead a red "eof" marker is placed where the final newline
ought to be.

require-final-newline obviously interferes with this. ethan-wspace could
therefore set it to nil when it is operating, unconditionally. However, I
added functionality to complain if require-final-newline was set -- not
because *users* set it, but because *modes* do, and I wanted to get notice
when that happened. So if you really think ruby-mode should unconditionally
set require-final-newline, it's easy to remove the warning, make it
optional, override require-final-newline on a buffer-local basis, etc.

Ethan



On Sat, Jul 5, 2014 at 2:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ethan Glasser-Camp <ethan.glasser.camp@gmail.com>
> > Date: Sat, 05 Jul 2014 14:07:16 -0400
> >
> > If ethan-wspace discovers that require-final-newline is set to t, it
> > admonishes the user.
>
> Why does ethan-wspace need to admonish users for setting
> require-final-newline?  Can this be avoided?
>

[-- Attachment #2: Type: text/html, Size: 1688 bytes --]

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Eli Zaretskii]

> From: Ethan <ethan.glasser.camp@gmail.com>
> Date: Sat, 5 Jul 2014 14:19:06 -0400
> Cc: 17947@debbugs.gnu.org
> 
> The idea behind the package is that bad whitespace is highlighted, not
> automatically cleaned up. So if the file doesn't have a final newline when
> it is first loaded, no final newline will be added without explicit user
> action -- instead a red "eof" marker is placed where the final newline
> ought to be.
> 
> require-final-newline obviously interferes with this. ethan-wspace could
> therefore set it to nil when it is operating, unconditionally. However, I
> added functionality to complain if require-final-newline was set -- not
> because *users* set it, but because *modes* do, and I wanted to get notice
> when that happened. So if you really think ruby-mode should unconditionally
> set require-final-newline, it's easy to remove the warning, make it
> optional, override require-final-newline on a buffer-local basis, etc.

It seems to me that if the buffer being checked has
require-final-newline set to a non-nil value, ethan-wspace should
simply refrain from checking the final newline, because obviously the
user and/or the mode took control of that issue.  Wouldn't this be
better than bitching at users for setting this option?

And I don't think introducing yet another option would solve it.  If
the user or mode set require-final-newline, IMO that is a clear
declaration that the final newline issue is that user's or mode's
responsibility; no further options are needed to make that clear.
Don't you agree?

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Stefan Monnier]

> One user reported that ruby-mode triggers this warning. Sure enough, in
> ruby-mode.el at line 287, I see:
>   (set (make-local-variable 'require-final-newline) t)

Removed in the `emacs-24' branch.  It was a remnant from before ruby-mode
was made to inherit from prog-mode.


        Stefan

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 05 Jul 2014 14:38:45 -0400
> Cc: 17947-done@debbugs.gnu.org
> 
> > One user reported that ruby-mode triggers this warning. Sure enough, in
> > ruby-mode.el at line 287, I see:
> >   (set (make-local-variable 'require-final-newline) t)
> 
> Removed in the `emacs-24' branch.

Regardless of what this or that mode does, I think it's wrong for
ethan-wspace to annoy users for having require-final-newline set
non-nil.

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Stefan Monnier]

>> > One user reported that ruby-mode triggers this warning. Sure enough, in
>> > ruby-mode.el at line 287, I see:
>> >   (set (make-local-variable 'require-final-newline) t)
>> Removed in the `emacs-24' branch.
> Regardless of what this or that mode does, I think it's wrong for
> ethan-wspace to annoy users for having require-final-newline set
> non-nil.

It's his package and he's free to do what he wants with it, I think.
Maybe I'd find it annoying as well, but in any case the setting was
erroneous since there is no justification to ignore the
mode-require-final-newline setting.


        Stefan

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 17947@debbugs.gnu.org,  ethan.glasser.camp@gmail.com
> Date: Sat, 05 Jul 2014 19:02:05 -0400
> 
> >> > One user reported that ruby-mode triggers this warning. Sure enough, in
> >> > ruby-mode.el at line 287, I see:
> >> >   (set (make-local-variable 'require-final-newline) t)
> >> Removed in the `emacs-24' branch.
> > Regardless of what this or that mode does, I think it's wrong for
> > ethan-wspace to annoy users for having require-final-newline set
> > non-nil.
> 
> It's his package and he's free to do what he wants with it, I think.

Yes, he is.  Which is why I said "I think".  It's an opinion of an
Emacs user who has this variable customized since about forever, and
would find it annoying to be annoyed by such warnings.  User who
customized this variables clearly tell that they want to be in control
of the final newline, so packages that look at that shouldn't.

bug#17947: 24.3; ruby-mode sets require-final-newline unconditionally

[Ethan]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

Hi Eli, if you are happy with the behavior of require-final-newline, then
that's fine and I don't believe you are likely to want to use ethan-wspace.
The point of the warning is to make it clear to a user that you can use
ethan-wspace, or require-final-newline, but not both. The point of the bug
report is merely to ask that if a user wants to use ethan-wspace and not
require-final-newline, that they be able to do so.

Thanks Stefan for the quick turnaround on the patch and the context for why
the code is the way it is!

Ethan



On Sat, Jul 5, 2014 at 10:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: 17947@debbugs.gnu.org,  ethan.glasser.camp@gmail.com
> > Date: Sat, 05 Jul 2014 19:02:05 -0400
> >
> > >> > One user reported that ruby-mode triggers this warning. Sure
> enough, in
> > >> > ruby-mode.el at line 287, I see:
> > >> >   (set (make-local-variable 'require-final-newline) t)
> > >> Removed in the `emacs-24' branch.
> > > Regardless of what this or that mode does, I think it's wrong for
> > > ethan-wspace to annoy users for having require-final-newline set
> > > non-nil.
> >
> > It's his package and he's free to do what he wants with it, I think.
>
> Yes, he is.  Which is why I said "I think".  It's an opinion of an
> Emacs user who has this variable customized since about forever, and
> would find it annoying to be annoyed by such warnings.  User who
> customized this variables clearly tell that they want to be in control
> of the final newline, so packages that look at that shouldn't.
>

[-- Attachment #2: Type: text/html, Size: 2246 bytes --]