Re: Fixes position of mensural c clef (issue 6503091)

[Graham Percival]

On Sat, Sep 08, 2012 at 01:01:15AM +0000, address@hidden 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