Graham Percival wrote Wednesday, June 22, 2011 12:30 AM
Another problem is that the scripts/auxiliar/fixcc.py depends on emacs, but emacs’ formatting changes between versions. ** Eliminate tabs I’m going to make the bold step of assuming that we will eliminate tabs in all C++ files. I personally like the idea of tabs, but from an examination of source code styles (both official and unofficial) in various projects, I must admit that this ship has sailed.
+1 Tabs were useful before keyboards had auto-repeating keys, and still are when laying out tables with fixed width columns. But the mixed tabs and spaces required to lay out code with varying indentations is just a nuisance.
Not everybody has emacs installed, and the C++ formatting varies between versions. That said, we could probably avoid that problem by giving a custom .el file with the C++ formatting from whichever version of emacs we prefer (23.1.1, 23.2, ...?)
Include in build dependencies? Which version is not important, but definitely must be fixed.
There’s also the consideration of how much energy we want to spend arguing about this. My preference is just to say "screw it, let’s just use fixcc.py strictly". I don’t like tying the code formatting to a specific text editor (much less one whose formatting changes with different versions!), but astyle and uncrustify just don’t seem "there" yet.
Neither do I, but the alternative of defining *precisely* our specific
c++ formatting rules is too horrendous.
** Implementation notes No plan for how to do this yet; it will be a mess.
Fix a date for the conversion and convert all files in origin/master on that date. Publicise it well so developers are fully aware and can do the same on their own branches. Any old patches not yet applied will (possibly) break, but they are known and can be relatively easily fixed, as you say:
somebody applies the patch to the un-indented source code, then run the indentation tool, then make a new patch,
It doesn't have to be the original contributor who does this as no code changes are involved. Trevor _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
