On Mon, 16 Jan 2012 23:32:00 -0500, Austin Clements <amdragon@mit.edu> wrote:
> Cleanup is the type of pain that should only be suffered once, so I'd
> be much happier with this if there was an accompanying git hook that
> prevented more mis-formatted code from slipping in.

We'd need a script to be called from .git/hooks/pre-commit to do
extra checking; developer needs first activate this pre-commit
and then add call to our checking routine. Imagine the amount
of false positives this hook starts to generate...

... but. developer can run 'git commit --no-verify' ...aargh no;
I guess if pre-commit hook fails, commit-msg hook is not run
and this is bypassed; maybe NO_FORMATCHECK_HOOK=1 git commit ...
is the answer.

But what we at least need is Guidelines document that states 
these formatting issues clearly and precicely. Surely 
self-respecting programmers understands to follow there (and soon 
adjusts their workflow -- i.e. activate/run these checkers
after list response).

> Quoth Tomi Ollila on Jan 16 at 11:04 am:
> > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> > index 00ed589..7b63348 100644
> > --- a/emacs/notmuch-lib.el
> > +++ b/emacs/notmuch-lib.el
> > @@ -143,7 +143,7 @@ The result is a new function which does the same as FUN, except that
> >  the first N arguments are fixed at the values with which this function
> >  was called."
> >     (lexical-let ((fun fun) (args1 args))
> > -     (lambda (&rest args2) (apply fun (append args1 args2))))))
> > +		(lambda (&rest args2) (apply fun (append args1 args2))))))
> 
> Ack.  What happened here?  This shows up in at least one other place,
> too.  I'm betting you need to load cl in some form to get the
> indentation rule for lexical-let.

Yes, thanks. (require 'cl) fixes that. I'll mark this and the RFC patch
(of batch-tools.el) obsolete. 

Tomi