On Mon, Jun 06, 2011 at 10:58:11AM +0200, Karl Hammar wrote: > Graham: > > (this proposal will be rushed because nobody will argue against > > it. Initial discussion 6 June, summary and tentative decision 8 > > June, implementation 10 June) > > Having set a policy about policy discussions and then breaking it > the first thing you do is not a good policy. > > If there is no rush, don't break the rules. On the contrary, how > can I feel confidence in the rules if they are beeing broken.
Very good point. I felt a bit of a rush because the mix of indentation is delaying some much-needed improvements to our build system, but I agree that this was completely contrary to my "let's take time to make sure it's good" approach. I have adjusted the schedule accordingly. > > * never max tabs and spaces > > In the code I presume, in strings this wouldn't apply. Yes. > > * Code indented with a mixture of tabs and spaces should be > > converted to using spaces exclusively > > Presenting rules without rationales, gives no ground for decisions. > One could the feeling that this is pure nonsense. If you really > care about this, provide a pretty printer instead, and stipulate > that all code should go through that. I am not aware of any pretty printers for python code -- remember that unlike C++ or scheme, indentation in python is the way that one indicates code blocks. (this makes mixing tabs and spaces particularly horrible!) I will certainly be giving specific recommendations for a pretty printer for C++ when we get to that stage, but as far as I know, the identation of python files must come from a human. > I propose instead: > > . Don't ever provide patches whith white space changes (in the code) > unless the patch is only about white space changes I will need to think about that a bit more -- I don't think it will be necessary for python files. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
