bug#25157: 26.0.50; whitespace-cleanup does not remove single trailing empty line anymore

[Reuben Thomas]

On 20 December 2016 at 04:36, <npostavs@users.sourceforge.net> wrote:

tags 25157 confirmed
quit

Mark Karpov <markkarpov@openmailbox.org> writes:

> The ‘whitespace-cleanup’ command does not remove single trailing empty
> line anymore.

​​I can reproduce this; sorry!

 

-(defcustom whitespace-empty-at-eob-regexp "^\\([ \t\n]+\\)"
+(defcustom whitespace-empty-at-eob-regexp "^\\([ \t\n]*\\(\n\\{2,\\}\\|[ \t]+\\)\\)\\'"

I don't quite understand why this more complicated _expression_ is
necessary.  Reuben, can you explain?

​With the previous regexp, whitespace-cleanup would remove a single newline at the end of a buffer.

I think I tried to be a bit too clever.

Thinking again, what we require is:

Match at the end of the buffer, either:

a. A mix of spaces and tabs, or

b. Optional whitespace followed by a newline followed by whitespace.

These two categories are not mutually exclusive (which is fine, and avoids being too clever).

The point is that if there are any newlines, there must be at least two.

Also note that the regexp does not need to be anchored at the start of a line (I'm not sure why I thought it did).

So, I think a correct regexp, directly translating the above, is: \\([ \t]+\\|\\([ \t\n]*\n[ \t\n]+\\)\\)\\'

However, there's still a problem: while this regexp will not match a single newline at the end of a buffer, when it does match any number of newlines (with or without extra space), it will remove all of them, whereas it should leave a single newline.

I can't see a way around this purely in the regexp, because if for example the end of the buffer is:

\t\n\t

then the regexp should match (and this one does), but whitespace-cleanup should leave a newline.

So I think a further change to the code is needed to whitespace-cleanup: when whitespace-empty-at-eob-regexp is matched, it should check match-string, and if it contains a newline, it should insert a newline in the buffer after deleting the matched string.

Given my previous error of reasoning, I'm submitting the above for your consideration before I prepare a patch!

--

http://rrt.sc3d.org