I'd like to be able to set my "indentation level" to 4 and leave the tab stops at 8. That is, if I hit my tab key the cursor should move as if my tabs stops are set at 4 (any any spaces required should be added). If there are any actual tab characters in the file, the file should display as if I had selected 8 as my tab size. (Basically this is because I edit files that other people have edited using emacs which "intelligently" uses tabs where it can to fill in sequences of 8 spaces.)
I was playing with the notion of expanding all the tabs to spaces so that it will display properly even if I have my tab size set to 4, but I'm afraid this will cause lots of extraneous differences when I check in my changes to CVS.
Another item is that when I'm working in Tcl I want my indentation level to be 4 characters. When working in PL/SQL I want it at 8. (Probably in C or C++ I'd want 2 or 3.)
On 27.12.2004, at 21:05, Patrick Kelly wrote:
I'd like to be able to set my "indentation level" to 4 and leave the tab stops at 8. That is, if I hit my tab key the cursor should move as if my tabs stops are set at 4 (any any spaces required should be added). If there are any actual tab characters in the file, the file should display as if I had selected 8 as my tab size. (Basically this is because I edit files that other people have edited using emacs which "intelligently" uses tabs where it can to fill in sequences of 8 spaces.)
One uses tabs *or* spaces to indent, not some mixture of the two -- that's madness. People speak so highly of emacs; it can't possibly force this behavior. It must be possible to tell it not to do that. And I don't see any need for TextMate to provide workarounds for other people's broken editor configurations. Adding a feature to TextMate to deal with this lunacy just makes for more-confusing preferences and application bloat for I would hope the majority of users whose coworkers have their editors set up reasonably.
On Dec 29, 2004, at 1:15 AM, Ryan Schmidt wrote:
On 27.12.2004, at 21:05, Patrick Kelly wrote:
I'd like to be able to set my "indentation level" to 4 and leave the tab stops at 8. That is, if I hit my tab key the cursor should move as if my tabs stops are set at 4 (any any spaces required should be added). If there are any actual tab characters in the file, the file should display as if I had selected 8 as my tab size. (Basically this is because I edit files that other people have edited using emacs which "intelligently" uses tabs where it can to fill in sequences of 8 spaces.)
One uses tabs *or* spaces to indent, not some mixture of the two -- that's madness.
I don't use tabs myself for indentation, but that mixture is what you get when you do use tabs and have to line up stuff like parameters in function calls, exception clauses, hash constructors, lists of implemented interface, etc.
In those cases it can happen that the conventional place to align vertically (an open paren for instance) may not be a multiple of the configured tab width. Thus the editor fills the rest with spaces.
-- fxn
Madness or not I work in an environment where everybody uses emacs and that's the way it behaves. Even if there is an option to "fix" emacs, I doubt I'll convince everybody else to switch to accommodate my perverse use of some obscure editor. Especially since this seems like the correct behavior for everybody using emacs.
Personally I believe that emacs got it right, that tab widths should always be at 8, and editors should indent intelligently with spaces as needed. (Actually it's kind of a bummer that tab characters go into text files at all, ever. Just like the whole confusion over what is a line (cr, crnl, nl).)
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.
Do menu selection changes get recorded in macros? How can I automate switching between 4 and 8 tab widths?
On Dec 28, 2004, at 4:15 PM, Ryan Schmidt wrote:
On 27.12.2004, at 21:05, Patrick Kelly wrote:
I'd like to be able to set my "indentation level" to 4 and leave the tab stops at 8. That is, if I hit my tab key the cursor should move as if my tabs stops are set at 4 (any any spaces required should be added). If there are any actual tab characters in the file, the file should display as if I had selected 8 as my tab size. (Basically this is because I edit files that other people have edited using emacs which "intelligently" uses tabs where it can to fill in sequences of 8 spaces.)
One uses tabs *or* spaces to indent, not some mixture of the two -- that's madness. People speak so highly of emacs; it can't possibly force this behavior. It must be possible to tell it not to do that. And I don't see any need for TextMate to provide workarounds for other people's broken editor configurations. Adding a feature to TextMate to deal with this lunacy just makes for more-confusing preferences and application bloat for I would hope the majority of users whose coworkers have their editors set up reasonably.
Personally I believe that emacs got it right, that tab widths should always be at 8, and editors should indent intelligently with spaces as needed. (Actually it's kind of a bummer that tab characters go into text files at all, ever. Just like the whole confusion over what is a line (cr, crnl, nl).)
M-x eval-expression Ret (setq tab-width 4) Ret in Emacs will set tabulation stops at 4 positions intervals. That's what many do.
David
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 before committing with a relatively simple script. That would avoid the meaningless diffs, but adds a small amount of extra work for you. I'd wrap your checkout and commit commands with a script to expand to spaces on checkout or update, and contract to emacs tab+spaces before commit. After a commit, you do an update and everything goes back to "normal" in your working copy.
Best, Eric
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
A solution is to make an (advanced) option to change the tab-width independent of the normal tab-size. Per default, the tab-width would mirror the tab-size so pressing tab (in non-emulation mode) would insert a tab character, but as an advanced setting you can set tab-width to 8, while size is 4.... but I don't blame Allan if he doesn't want to implement something like this.. It could be a mess :-p.
I have no idea why emacs uses this method (in its most usual setup), but maybe to keep tab-width at 8 so it works with older apps and e.g. HTML and such? But then, why not only use spaces and never tabs like when TM is in emulation mode?... weird :-p.
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
On Dec 27, 2004, at 21:05, Patrick Kelly wrote:
I'd like to be able to set my "indentation level" to 4 and leave the tab stops at 8. [...]
I'm afraid I'm with Ryan on this one. I do see your problem though, hopefully you can solve it with CVS wrappers. I'll keep it in mind for the future in case it should be easy for me to support, though most likely via a hidden preference ;)
Another item is that when I'm working in Tcl I want my indentation level to be 4 characters. When working in PL/SQL I want it at 8. (Probably in C or C++ I'd want 2 or 3.)
In 1.1.x (not fully decided on which) it will be possible to apply settings, styles, macros, snippets, commands etc. (for the latter, mainly the trigger/key equivalent) to single language elements addressed similar to how CSS selectors address HTML elements (that's why I have the name in the syntaxes files) and with this will then be the possibility for doing things like mode-specific settings.
-
Allan Odgaard -
David Tolpin -
Eric Ocean -
Patrick Kelly -
Ryan Schmidt -
Sune Foldager -
Xavier Noria