On Monday 21 January 2008 13:27, Graeme Geldenhuys wrote: > On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > But how would it solve > > > > |type > > | FooBar = (Foo, > > | Bar); > > Look at the flash demo on the website for an example of this! > Lets say gEdit (linux editor) has support for ET. > > You would type > > type > <tab>FooBar = (<tab>Foo, > <tab>Bar );
Yes, that's what I figured. But that's wrong. Only legasthenic retards[1] put spaces at the inside of parentheses. > type > FooBar = ( Foo, > Bar ); Yes. And that's precisely what I *DON'T* want: Spaces to break the reading flow. To be more clear on the subject: Parentheses are not operators, although a lot of people like to treat them so in source code while they miss to put the spaces around the real operators.[2] > The other nice thing is, it's font independent. You can even use > variable width fonts and it will still line up correctly. I know. I've read about this before (I think it was mentioned on the "Embedded Muse" a while ago). >> Whenever > you press TAB, it tries to find the closest TabStop (a tabstop is NOT > a tab character) normally from the lines before it. Then when you > save, it can convert the alignment to spaces. And when it reloads, everything "semantic" you put in with the tab stops, got lost. Effort wasted, file needs to be reformatted. > As I said, it took me a while to fully understand ET as well. :) All I understood so far is the same as with all the other tools: If you write your code like a moron to suite the tool, the tool suits you.[3] To put it more bluntly: Code formatting does not follow strict rules, there are always some heuristics involved. So even two different formatting of the same code may not violate coding style. Now, a tool can choose whatever heuristic it wants, there *will* be corner cases where the tool will fail, no matter what heuristics it chooses. That's inherent to heuristics. Following stricter rules only leads to harder-to-read code (like the code with the misplaced parentheses). Vinzent. [1] No offense, it's not meant personally. But as someone who reads a whole Tom Clancy on a 5-hour train ride, I'm accustomed to a certain style. And that also means, any deviation from that slows me down considerably. [2] Now that I know whose tool is responsible for that I can go and shoot the author. ;) [3] Also see [1]. I don't need tools to slow me down. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal