On Sat, Sep 08, 2012 at 01:01:15AM +0000, lemzw...@googlemail.com wrote: > >I mean, in this file there's a weird mixture of tabs and spaces > > Weird? It's always tabs (which is assumed to be represented visually by > eight spaces on screen) followed by less than eight spaces.
However, some editors use 4-space tabs. In general, I think it is undesirable to assume that tabs will always be 8 spaces. I think some of the confusion could be avoided by running all mf files through expand(1). > I'm really bewildered that it is apparently so hard for many > contributors to format and indent new code in the same manner as the > surrounding code. Is this lack of experience? Is this ignorance? Is > it arrogance? I would rather keep this neutral from any accusation of ignorance or arrogance -- in *both* directions. I could easily argue it either way. Let's say "lack of experience with 1980s and 1990s unix text formatting conventions". In those old days, whether it was due to limited disk space or character-based teletype machines or something else, there was widespread awareness of tab characters vs. space characters. These days, there is not so much fondness for this distinction. For example, python gives warnings if you use tabs instead of spaces, and in my own personal vim settings I use "soft tabs" (plus tabstop=4) meaning that a tab key indicates 4 spaces, and pressing a delete key if the cursor is in front of 4 spaces will result in deleting 4 spaces. The bottom line is this: as you noted, many contributors find it difficult to format and indent code exactly like the surrounding code including a mixture of tabs and spaces. I see four options: 1. reject any offers of help from contributors who do not follow the existing formatting. 2. educate each contributor individually, go through multiple rounds of each patch to adjust the formatting, etc. 3. use an automatic formatting tool. 4. combine 2 and 3: use an automatic formatting tool for most of the code style, but still require some additional manual formatting (and go through a few rounds of reviews if necessary). I favor either 3 or 4; we are not in a position to be gratuitously rejecting patches, and having "finicky" manual formatting will discourage some contributors. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
