[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bugs in dirname module - coreutils portion
From: |
Jim Meyering |
Subject: |
Re: bugs in dirname module - coreutils portion |
Date: |
Thu, 24 Nov 2005 23:48:44 +0100 |
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.