Bruno Haible wrote:
> Hi,
> 
> I see that some of you are starting to untabify C source code (Jim in
> lib/userspec.c, Eric in lib/pipe-safer.c). Is this a signal that we can
> finally put those annoying TAB characters at rest? [1] I would love it.
> 
> Just 2 questions:
> 
>   - Since GNU Emacs defaults have certainly not changed: What is the
>     piece of code that we can recommend users to put into their Emacs
>     configuration? Does everyone agree with
> 
>       ;; Don't use tabs by for indentation. Spacer are nicer to work with.
>       (setq-default indent-tabs-mode nil)

coreutils HACKING contains:

  ;; In coreutils, indent with spaces everywhere (not TABs).
  ;; Exceptions: Makefile and ChangeLog modes.
  (add-hook 'find-file-hook '(lambda ()
    (if (and buffer-file-name
             (string-match "/coreutils\\>" (buffer-file-name))
             (not (string-equal mode-name "Change Log"))
             (not (string-equal mode-name "Makefile")))
        (setq indent-tabs-mode nil))))

> 
>     of for vim
> 
>       " Don't use tabs by for indentation. Spacer are nicer to work with.
>       set expandtab

I also set this for vim:
 filetype indent on
which uses TABs for Makefiles as required.
That doesn't handle Changelogs though, so for
situations like that I also have this setting:
  "Shift-tab to insert a hard tab
  imap <silent> <S-tab> <C-v><tab>

> 
>     Can I put this in the gnulib README?
> 
>   - How do we deal with untabifying of existing code? In commits like
>     
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6ed67a15a265e213d2cbaac25ccc995fddf73ac6
>     (both in gitk and on the web) I have to read the code change
>     line by line to understand there was only whitespace change. I'd like
>     to propose to untabify in separate commits, i.e. not mix untabify
>     and real changes in one commit.

Well coreutils recently untabified the whole project so this issue is moot:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=5e778f7c
I hate when whitespace only changes are mixed with logic changes,
so I would discourage it.

One tip I would give when using `git blame` is to use the -w option.

cheers,
Pádraig.



Reply via email to