Re: bugs in dirname module - coreutils portion

[Jim Meyering]

address@hidden (Eric Blake) wrote:
...
>> Perhaps you put the source code through a tab normalizer?  If so,
>> please undo all changes of that sort.
>
> I normally run emacs with
>  (add-hook 'before-save-hook 'whitespace-cleanup)
> That was the culprit.  I guess I should file a bug with emacs that
> whitespace.el should not normalize spaces inside string literals.

Three types of whitespace changes are welcome in coreutils: removing
trailing blanks, removing useless spaces before TAB characters, and
removing blank lines at the end of a file.  Ideally, we'd also convert
all leading TABs to sequences of spaces, but that's not an option --
too much risk of causing pointless conflicts down the road.

> Meanwhile, is there an easier way to run emacs whitespace-cleanup
> to catch trailing whitespace and space-before-tab issues without
> also being forced to turn on the 8-spaces-vs-tab cleanup?  What
> settings do you use for whitespace happiness during editing?

I recall not liking some of the things that Emacs' whitespace.el
did when I tried it a year or two ago.  I've been using this for
far longer:

  ;;; From Noah Friedman
  ;;; http://www.splode.com/users/friedman/software/emacs-lisp/
  (autoload 'nuke-trailing-whitespace "whitespace" nil t)
  (add-hook 'mail-send-hook 'nuke-trailing-whitespace)
  (add-hook 'write-file-hooks 'nuke-trailing-whitespace)

  (defvar nuke-trailing-whitespace-p 'ask)
  (defvar nuke-trailing-whitespace-never-major-modes nil)

I also use always-font-lock-keywords to highlight the offending
white space.

>> It might be better, for a larger change like this, to do the
>> tab-normalization changes separately anyway, so that we can see the
>> more-important stuff easily.
>
> I'll regenerate with diff -b, to mask the whitespace changes
> (I don't have commit rights yet, so someone else will end up
> applying my final patch anyway).

Please don't use `diff -b' to do that.
Otherwise, anyone applying your patch can easily end up with
incorrectly indented code.  Sometimes it's useful *in addition*
to regular diff -u output, especially when there have been
indentation changes spanning many lines.

I try hard to keep purely white-space-changing (and any other global
text-substituting) deltas separate from others.