Yes, I suppose this is a philosophical difference of whether or not the compiler should enforce coding style. :)
Edward Excerpts from Simon Marlow's message of Sat Aug 24 13:21:30 -0700 2013: > There's some justification for -fwarn-tabs: tabs can lead to confusing > failures when people use the wrong tab setting in their editor. On the > other hand, I don't think there's any good reason for having the > compiler warn about trailing whitespace. > > Cheers, > Simon > > On 22/08/13 17:18, Edward Z. Yang wrote: > > GHC already has -fwarn-tabs; we could have -fwarn-trailing-whitespace > > and turn it on by default, so that validate errors on it but you also > > notice it when you're doing a build (if you're paying attention to > > warnings). > > > > Edward > > > > Excerpts from Simon Marlow's message of Thu Aug 22 05:04:50 -0700 2013: > >> On 22/08/13 12:32, Austin Seipp wrote: > >>> This seems acceptable IMO. The general working conventions already are > >>> to separate whitespace and/or tab changes from a commit containing > >>> actual content. If you ./validate cleanly, but the server rejects the > >>> push for whitespace, adding an extra commit on top to clean up the > >>> affected files seems very sensible (it's simple to 'untabify' and > >>> eliminate trailing white space in most editors these days, so I imagine > >>> this isn't really going to cost you a lot of time.) > >> > >> You still have to validate the new commit, so it costs you at least 20 > >> mins, which is a lot. > >> > >>> I also add bonus > >>> points for the fact the server will reject it unless you clean up *all* > >>> affected files you touched, so things can't slip by. This is how the tab > >>> check works now, and it does deal with a 'range' of commits where later > >>> commits eliminate tabs introduced in earlier ones. > >>> > >>> We'd also have to introduce the concept of git into ./validate for this > >>> to work (and add the ability to specify a commit range for stuff like > >>> this,) but a basic implementation may not be difficult, looking at the > >>> pre-receive script. > >> > >> Checking everything in 'git rev-list origin..' is probably good enough. > >> > >> Cheers, > >> Simon > >> > >>> Alternatively, these could be pre-commit hooks in the developer > >>> repository, but I believe you have to opt into that. Maybe worth putting > >>> on the wiki, though. > >>> > >>> > >>> > >>> On Thu, Aug 22, 2013 at 2:33 AM, Simon Marlow <marlo...@gmail.com > >>> <mailto:marlo...@gmail.com>> wrote: > >>> > >>> On 20/08/13 12:21, Geoffrey Mainland wrote: > >>> > >>> Would be nice to have. How about a third hook that disallows > >>> commits > >>> that include whitespace-only changes unless *all* changes are > >>> whitespace-only? ;) > >>> > >>> > >>> The problem with these kind of commit-time checks is that you only > >>> find out the problem *after* you've validated your nicely polished > >>> commits. If we're going to add more checks on commits they should be > >>> done by validate (yes I know that's not at all trivial, but it's not > >>> impossible either). > >>> > >>> Cheers, > >>> Simon > >>> > >>> > >>> > >>> > >>> Geoff > >>> > >>> On 08/20/2013 10:59 AM, Jan Stolarek wrote: > >>> > >>> Right now we have a git hook that prevents pushing a file > >>> containing tabs, unless that file had them already (in other > >>> words: no new files with tabs in our repos). I propose to > >>> add similar hook for trailing whitespaces. Herbert says he > >>> can implement that. What do others think? Would you find > >>> that useful or problematic? > >>> > >>> Janek > >>> > >>> > >>> _________________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > >>> http://www.haskell.org/__mailman/listinfo/ghc-devs > >>> <http://www.haskell.org/mailman/listinfo/ghc-devs> > >>> > >>> > >>> > >>> _________________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > >>> http://www.haskell.org/__mailman/listinfo/ghc-devs > >>> <http://www.haskell.org/mailman/listinfo/ghc-devs> > >>> > >>> > >>> > >>> > >>> -- > >>> Regards, > >>> Austin - PGP: 4096R/0x91384671 > >> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs