Dan McGee wrote:

On Wed, Feb 18, 2009 at 9:45 PM, Bryan Ischo wrote:

...

Dan McGee wrote:

...

You can wrap this if you want, ignore my earlier weird recommendations.

Are you talking about the line length issues you pointed out before? And are you saying here that it's OK to wrap the lines to fit 80 columns in my editor, rather than trying to match another environment?

I think that's what you're saying. I will henceforth wrap wherever makes the most sense for me. You hadn't commented on my comments before, but I think you agree that the pacman code style guidelines unfortunately cause problems like these. Using tabs for indentation only works for unbroken lines; as soon as a line is broken and the second half needs to be lined up on a non-tab-boundary (with function arguments on the second line lining up with those on the first, for example),

Here is the false statement. Lining things up makes for a hellish experience, and never seems to work right, and only encourages the spaces vs. tabs debate. Just let the editor do the hard work for you- I don't want it to line up at all. Two additional tabs is the standard going rate in our codebase, as this is what vim does by default anyways.

The only way lining them up makes sense is if your function name is super short- as soon as your function name and return type are more than 30 characters, you are just needlessly cramming everything over to the right.

Fair enough; I don't think we're likely to agree on indenting issues (my philosphy is "if emacs does it it must be right :)") but I am happy to obey the pacman conventions as necessary. I've thought about this issue a bit outside of this particular discussion and I think what would be awesome (and what I think I would do if I owned a project like pacman - although I'm not suggesting that the pacman devs ought to follow my ideas here), is for the checkin process to automatically run the 'indent' program on each source file to normalize the indentation to some vanilla predefined format, and the checkout process would run a user's custom version of indent to make the code look how they want. So in your own tree, you'd always be looking at code indented how you like, but the code as checked into the repository would always have a set indentation (otherwise, there would be pointless whitespace diffs in every checkin as people's locally-indented files change indentations on checkout). Of course the source control system would have to be smart enough to run indent as necessary when doing diffs as well, and probably there would be a million corner cases making the whole thing a nightmare but ... wouldn't it be so cool if everyone could have the source indented how they want it to be indented, all the time, in their own view of it, but the repository always used a single standard indentation style? I think it would be awesome! Bryan