Re: tabs vs. spaces in source code

[Graham Percival]

On Wed, Jul 29, 2009 at 10:12:11AM +0200, Francisco Vila wrote:
> Those two copyPasteable lines do work.

Thanks, added to the CG.

> $ emacs -batch vertically-spaced-context-engraver.cc --eval
> '(indent-region (point-min) (point-max) nil)' -f save-buffer
> 
> (tested on cc files, seems to leave them as they currently are)
> (tested on scm files, follows a slightly different convention, see diff below)

Let's tackle the cc files first.  I tried running it on everything
lily/*.cc, and ended up with a 126K diff.

1) many changes were simply moving */ to the left by 1 char.
   That's fine.
2) *lots* of changes were like this:
-----
@@ -46,7 +46,7 @@ Align_interface::calc_positioning_done (SCM smob)
   TODO: This belongs to the old two-pass spacing. Delete me.
 */
 MAKE_SCHEME_CALLBACK (Align_interface, stretch_after_break, 1)
-SCM
+  SCM
 Align_interface::stretch_after_break (SCM grob)
 {
   Grob *me = unsmob_grob (grob);
-----

This also looks fine to me, although I admit that I'm not certain
whether SCM is a macro or what.


3)  It screwed up one useful comment in axis-group-interface.cc:
 /* We want to avoid situations like this:
-           still more text
-      more text
+   still more text
+   more text
    text

that could be fixed by adding _ to the beginnings of the "more
text" lines, I guess.  Alternatively, is there a way to tell emacs
not to format a specific block of text?
(my preference would be to add _, though)


4)  I found one case where it fixed
  for (int j = CONTROL_COUNT - 2; j >= 0 ; j--)
  for (int i = 0; i < CONTROL_COUNT -1; i++)
    p[i][j] = p[i][j+1] + t * (p[i+1][j+1] - p[i][j+1]);
which looks like *terrible* code to me.  +1 bonus for auto-indent
use.  :)


5)  If we want to use this, we should wait until all major
branches are merged, because it will produce lots of really
annoying conflicts.


6)  If we want to use this, the patch needs to be examined
carefully.  There aren't many problems, but we definitely
shouldn't apply it blindly.  (we'd have lost that good comment
otherwise!)


Cheers,
- Graham