llvm dev - Apr 2005 - [LLVMdev] Trailing whitespace removal (important for CVS users!)

On 4/21/05, Chris Lattner <sabre at nondot.org>
wrote:
> On Thu, 21 Apr 2005, Reid Spencer wrote:
> > Why not put all this into a pre-commit filter in CVS and be done with
> > it? We'd never be bothered with it again as it would never be
committed
> > again.
> 
> I'd rather not have CVS commit scripts mucking with the code.  If you
want
> to have the nightly tester whine about source code with spaces at the end
> of lines (like it whines about compiler warnings), that would be fine.
> 
> BTW, does anyone know how to tell xemacs to autodelete end of line spaces?
> 
(defun kill-trailing-whitespace()
  "removes all whitespace at the end of every line in the buffer"
  (interactive)
  (end-of-buffer)
  (setq end (point-marker))
  (beginning-of-buffer) 
  ; set up for the first line
  (next-line 1)
  (beginning-of-line)
  (while (< (point) end)
	 (progn
		(set-mark-command nil)
		(re-search-backward "[^ &^	&^
]" nil)
      ; save the non-whitespace char
		(forward-char 1)
		(delete-region (point) (mark))
      ; put the <CR> we just deleted back
		(insert "
")
		(next-line 1)
		(beginning-of-line)	
	 )
  )
); end kill-trailing-whitespace
;=======================================================
-bw

On Thu, Apr 21, 2005 at 03:57:54PM -0500, Chris Lattner
wrote:
> On Thu, 21 Apr 2005, Reid Spencer wrote:
> >Why not put all this into a pre-commit filter in CVS and be done with
> >it? We'd never be bothered with it again as it would never be
> >committed again.
> 
> I'd rather not have CVS commit scripts mucking with the code.  
I think Reid means to have a script that *prevents* checkin of code that
does not conform to some standards, verified by a pre-checking script.
The script would *not* be auto-modifying code before/after checkin.

My only issue is that it slows down the commits for all committers...
But it would force everyone to follow the coding standard(s)!
> If you want to have the nightly tester whine about source code with
> spaces at the end of lines (like it whines about compiler warnings),
> that would be fine.
 
I was going to go that route, actually.
 
> BTW, does anyone know how to tell xemacs to autodelete end of line
> spaces?
% which xemacs
xemacs: aliased to vim

in other words, no clue. ;)

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Thu, 21 Apr 2005, Reid Spencer wrote:
> Why not put all this into a pre-commit filter in CVS and be done with
> it? We'd never be bothered with it again as it would never be committed
> again.
I'd rather not have CVS commit scripts mucking with the code.  If you want 
to have the nightly tester whine about source code with spaces at the end 
of lines (like it whines about compiler warnings), that would be fine.

BTW, does anyone know how to tell xemacs to autodelete end of line spaces?

-Chris
>> Dear LLVMers,
>>
>> If you live on the bleeding edge (i.e. CVS version), please read!
>>
>> On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer
wrote:
>>> Do you really want external patches for this ? A simple Perl script
>>> that runs on all *.h and *.cpp files, and a local commit from your
>>> side would be much simpler.
>>
>> I'm in the process of doing just this as we speak.  What this
means:
>> please hold off updating in the mean time, unless you want to rebuild
>> your codebase several times, as I am about to touch a *lot* of files.
>>
>> I will send a message to the list when I'm done, so you can get all
the
>> changes (and hopefully, few conflicts)
>>
>>> The testsuite should also be enhanced to daily report files with
>>> trailing whitespace.
>>
>> Good idea, I'll add that to my todo list.
>>
>>> Please note that this not purely academic - trailing whitespace are
a
>>> horror for anyone maintaining external patches against a CVS tree.
>>
>> I was not aware that this is such a big problem, so thanks for point
>> this out.  It'll be fixed in a short while.
>>
>
>
>
> _______________________
> Reid Spencer
> President & CTO
> eXtensible Systems, Inc.
> rspencer at x10sys.com
>
-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

On Thu, 2005-04-21 at 15:57 -0500, Chris Lattner wrote:
> I'd rather not have CVS commit scripts mucking with the code.  If you
> want 
> to have the nightly tester whine about source code with spaces at the
> end 
> of lines (like it whines about compiler warnings), that would be fine.
> 
> BTW, does anyone know how to tell xemacs to autodelete end of line
> spaces?
I am not sure about xemacs but in emacs you do:

M-x whitespace-cleanup

I have the following in my .emacs:

;; Function to untabify a buffer
(defun untabify-buffer () (interactive)
  (whitespace-cleanup)
  (untabify (point-min) (point-max)))

(global-set-key [f7] 'untabify-buffer)

So pressing F7 eliminates all tabs and trailing spaces. I used to have
this done automatically when saving a file, but that was causing more
problems than it solved (usually code is not clean - if I have the
setting in my .emacs it doesn't mean that everyone does).

-- 

Alkis

On Thu, 2005-04-21 at 15:51 -0500, Misha Brukman wrote:
> On Thu, Apr 21, 2005 at 03:57:54PM -0500, Chris Lattner wrote:
> > On Thu, 21 Apr 2005, Reid Spencer wrote:
> > >Why not put all this into a pre-commit filter in CVS and be done
with
> > >it? We'd never be bothered with it again as it would never be
> > >committed again.
> > 
> > I'd rather not have CVS commit scripts mucking with the code.  
> 
> I think Reid means to have a script that *prevents* checkin of code that
> does not conform to some standards, verified by a pre-checking script.
> The script would *not* be auto-modifying code before/after checkin.
Yeah, that's what I meant. While we're at it, you could run something
like "indent" to validate the coding style. It would just reject the
commit if it found problems.

Reid
> 
> My only issue is that it slows down the commits for all committers...
> But it would force everyone to follow the coding standard(s)!

True, but think about how much time we waste dealing with formatting and
style issues. Its a trade off. I'd rather have the computer think about
it than the developers. There's also lost productivity when faced with
unwarranted diffs and code in style that isn't conforming.

Reid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050421/f2faafde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050421/f2faafde/attachment.sig>