From: Tomi Ollila <tomi.ollila@iki.fi>
To: Austin Clements <amdragon@mit.edu>
Subject: Re: [PATCH 2/3] emacs: whitespace-cleanup and indent-region for
	emacs/*.el files
In-Reply-To: <20120117043200.GJ16740@mit.edu>
References: <cun7h0v7ete.fsf@hotblack-desiato.hh.sledj.net>
	<1326704656-26102-1-git-send-email-tomi.ollila@iki.fi>
	<1326704656-26102-2-git-send-email-tomi.ollila@iki.fi>
	<20120117043200.GJ16740@mit.edu>
User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Tue, 17 Jan 2012 12:46:23 +0200
Message-ID: <yf6obu261z4.fsf@taco2.nixu.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list

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