emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gratuitous changes


From: Miles Bader
Subject: Re: gratuitous changes
Date: Fri, 31 Jan 2003 21:11:04 -0500
User-agent: Mutt/1.3.28i

On Fri, Jan 31, 2003 at 04:48:16PM -0500, Stefan Monnier wrote:
> But I still think that what happened with keyboard.c is bad:
> turning every whitespace-only line into an empty line.  This is
> bad because hitting TAB somewhere or calling indent-region on
> a piece of code will re-introduce those spaces, so we end up
> with never ending spurious conflicts.

This is not true -- indent-region will not add spaces to an empty line, at
least in C or lisp code (it seems to try to preserve whitespace exactly,
which is obviously good for the sort of reason you give in your message).

In fact, emacs indentation commands in general seem to try to delete spaces
from empty lines when possible, e.g., C-j on an empty line filled with spaces
will remove the spaces before inserting a newline and indenting the new line,
and indent-rigidly will remove  spaces from empty lines.

The exception seems to be cases where it's expected that you will immediately
add text to the line, such as TAB, or C-j.  As I expect most people won't
randomly hit TAB on empty lines, I don't think this should be a problem.

> Please be careful when you commit changes.  Those of us who have
> extensive locally modified files (i.e. uncomitted changes)
> will be grateful for it.

This, OTOH, is very true.  I think it's OK to `fix' whitespace issues if they
occur immediately adjacent to a change you're already making, but otherwise
it can be quite annoying for people maintaing patches or CVS branches.

In particular, it's a bad idea to blindly use `delete-trailing-whitespace'
(e.g. in write-file-hooks) on files you're going to check in.

-Miles
-- 
97% of everything is grunge




reply via email to

[Prev in Thread] Current Thread [Next in Thread]