GNU bug report logs - #71499
[PATCH] Make whitespace.el cleanup add missing final newline

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Björn Lindström <bkhl <at> elektrubadur.se>, 71499 <at> debbugs.gnu.org
Subject: bug#71499: [PATCH] Make whitespace.el cleanup add missing final newline
Date: Thu, 13 Jun 2024 03:38:42 -0400

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> I thought about that, but since whitespace-cleanup generally applies
>>> clean-up according to white-space style, I thought it was simply an
>>> oversight that it doesn't apply a fix when it is set to highlight
>>> missing end-of-file newline.
>>>
>>> Adding a separate way to configure this removes the simplicity of
>>> configuring your preferred whitespace-style as a single option.
>>>
>>> However, If you still disagree I can make another patch somehow
>>> maintains the old behaviour as the default, so just let me know.
>>
>> Let's see what others think, and take it from there.
>>
>> Stefan, Andrea: WDYT about this change?
>
> AFAIU, the purpose of whitespace.el is to detect and eventually fix
> incorrect whitespace, and it has two ways of doing this:
>
> - Visual highlighting
> - Commands to fix problems (`whitespace-report` and
>   `whitespace-cleanup).
>
> Since it is mostly configured in the centralized option,
> `whitespace-style`, it seems natural that if a user wants to detect
> `missing-newline-at-eof`, she would also want this to be fixed by
> `whitespace-cleanup`.  This seems even more natural given that
> `whitespace-report` already considers that a problem worthy of
> reporting.  IOW, I tend to agree that this not already being the case
> looks like an oversight.
>
> So I think the existing options are fine, and the patch could go in
> as-is, despite the fact that it is backwards-incompatible.  If users
> really hate it, I guess we will hear about it and can react.
>
> If we want to be really cautious, we might want to consider waiting with
> this change until Emacs 31.  That should provide ample time for people
> to notice the new behaviour and react.
>
> My two cents.

I'm as well for having the patch in, but I guess would be safer in 31 so
we have plenty of time to react if needed.

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.