On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > You and I could have opened the same C file. Only you see: > > #include <stdio.h> > > int +--------------------+ > main ( int argc, | My first C program | > char *const argv[] ) +--------------------+ > { > (void) printf( "Hello world\n" ); > > return(0); > } > > while I see: > > #include <stdio.h> > > /* My first C program */ > int main(int argc, char *const argv[]) { > printf("Hello world\n"); > return 0; > }
Well no, for two reasons. Firstly, I think the first one looks disgusting, so even if I had that feature, I wouldn't use it like that :) But more importantly: You can already do that sort of thing, and it's a bad idea. Maybe there aren't any text editors that can do it, but you can use source control that way. (I'm going to use git as my example, as I don't know how it's done in hg or any other; but I'm sure it won't be hard.) You just tell git that these files (probably "files matching glob *.c") are to be reformatted, and provide two commands: one that cleans a file prior to it going into source control, and one that "smudges" it at the other end. So you could simply write a code reformatter and register it as your smudge command, and (in the interests of readable diffs) have some standardized reformatter as the clean command. Voila! You now can check out my code with your formatting. Which brings me to the second reason for not doing this. That clean/smudge operation *destroys information*. Once you enforce code formatting like that, you violate PEP 8's "rule zero": sometimes, it's better to break the rules. Sometimes, your nice code reformatting operation will actually make the program worse... and there'll be no way for you to get back from that. Not to mention that any reformatting that inserts or deletes lines is a pain for debugging. "Line 42" on your screen and "Line 42" in the traceback won't be the same thing any more. If I run your code and give you an exception trace, you'll have to check out my version of the code to be able to understand anything. Theoretically that could be solved (eg you absolutely always run the checked-in version - of course, that assumes that everyone's smudge and clean will perfectly recreate the exact same output), but even with editor support, where you'd move the cursor around and the line number would go berserk (press down-arrow three times and the line number goes 5, 6, 6, 10), it would be a pain. Code is a text file. So is music (I use GNU LilyPond, and everything works like code). So is data, in many many cases. So is configuration, often, although some programs prefer to work with an opaque format. About the only thing that really definitely shouldn't be massaged into text is actual 2D images. Can you turn this into a few lines of code? https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/AAAAAAAABU8/QvExuUq47dI/s512/DSCF7600.JPG Pretty much everything else, though, works better as plain text. ChrisA -- https://mail.python.org/mailman/listinfo/python-list