If I write this...
1. function something(parameter) { 2. if (condition) { 3. statement; 4. } 5. }
...then line 3 is intended twice, lines 2 and 4 are indented once, and lines 1 and 5 are not indented at all. I hope everyone can at least agree on that. I personally prefer to indent by the width of 4 spaces and have my editor configured to show tab characters this way. Perhaps later I will decide to reduce this to 3 spaces. To make this change, I merely have to open my editor preferences and change one value. I object to others forcing their indentation width preferences on me by giving me documents which are indented entirely with space characters. For this reason I assert that people SHOULD use tab characters to indent -- at least at the beginning of a line. (I am, however, against using tabs in the middle or at the end of a line, because that again has the effect of linking tabs to a particular number of spaces.)
And this (yes, I'm gonna call it) "emacs style" indentation where, in the above example, line 3 is indented with a tab, and lines 2 and 4 are indented with 4 spaces, is the epitome of stupidity and shows a complete lack of understanding of the purpose of tabs. The tab character is not a shorthand way to write 8 spaces. It is a way to indicate that the text should be indented once more. Creating a document in this emacs style says "my editor wants to use 8 spaces for tabs, but I want 4, and I'm gonna work around the problem rather than correct my editor's settings." And it absolutely forces the viewer of the file to have an editor that uses exactly 8 spaces (no more, no less) for a tab character. That's not how I have my editor set up, therefore that's rude.
So, the real problem is that emacs has a mode which allows this mess. If emacs didn't have such a mode, such files would never come into existence. Why compound the problem by giving this misfeature to another editor?
If one does have to work with and maintain such braindead indentation policies, I'm with Eric that one should write encoder and decoder scripts. But the IMHO correct solution is to check out the files, fix them to correct tab usage, and check them back in (with a checkin comment like "fixed braindead indentation"), and force everybody else to fix their editor settings. I mean, God help us if we had to program workarounds for every user who couldn't be bothered to properly configure their computer.
On 29.12.2004, at 10:51, Xavier Noria wrote:
On Dec 29, 2004, at 10:32 AM, Eric Ocean wrote:
On Dec 28, 2004, at 5:01 PM, Patrick Kelly wrote:
Like I said, it may be possible for me to rid the files I edit of all tabs by using the expand unix utility. The problem with that is causing large, meaningless diffs when I checkin my changes to CVS.
You could always convert back to emacs style
I think calling that "emacs sytle" or relating this issue to emacs as in other messages is not fair.
That's the configuration those folks happen to have. Of course emacs can be configured to use soft tabs, and of course ANY editor that allows hard tabs will have to mix tabs and spaces to line up certain things. The mixture is the price you pay for using hard tabs in ANY editor.
So the real problem is that the OP is not following the convention of the team regarding soft/hard tabs. Not that the convention is wrong.
-- fxn
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate