| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 4/3 |
| 2004/9/16 [Computer/SW/Editors/Emacs] UID:33555 Activity:high |
9/15 Spaces or tabs? I was almost converted to the tab true religion,
and then I tried to actually set this up in emacs. I find code with
eight character wide tabs to be less readable. This is totally a
personal preference, if you like reading code with eight character
wide tabs, more power to you. Simple enough to fix, right, just:
(setq tab-width 4)
and, voila, my eyes stop bleeding from overexposure to white space.
Not so fast! Suppose you're editing in cc-mode with a style that
sets c-basic-offset to 8. cc-mode now inserts two tabs, which is
definitely not the desired behavior. See:
http://csua.org/u/92a
for a discussion of this on the emacs-devel list. Note RMS smacking
the original poster down. Thoughts, suggestions? What do folks
using other editors do?
\_ never use tabs in public text files. end of story. spaces are
always spaces, tabs are a mess.
\_ http://csua.com/?entry=12521
\_ Check out astyle. I use 3 spaces.
\_ Sounds similar to gnu indent. I was kind of hoping for
something better than configuring [ your favorite revision
control system ] to slam everything through [ your favorite
code reformatting tool] at checkin time. Thanks for the input
though. -op
\_ http://www.jwz.org/doc/tabs-vs-spaces.html "My opinion is
that the best way to solve the technical issues is to
mandate that the ASCII #9 TAB character never appear in
disk files: program your editor to expand TABs to an appropriate
number of spaces before writing the lines to disk"
\_ I prefer pressing the TAB key goes to tab stops (whether they're
every 8- or 4- or user-defined # of spaces), but spaces are actually
output. I prefer setting my editor to default to stripping all
trailing spaces and converting all tab characters to spaces when
saving. Too bad jove (ancient, I know) doesn't do all this, emacs
is too big, but my Windows editor TextPad does all this.
Does anyone know a tight little non-GUI UNIX editor that I can
configure to do all of this by default?
\_ i'd be surprised if some vi/vim version can't do it.
\_ yeah, I guess I just need to track down all the .vimrc magic |
| csua.org/u/92a -> lists.gnu.org/archive/html/emacs-devel/2002-06/msg00380.html Thread Index the overloading of tab-width' From: Colin Walters Subject: the overloading of tab-width' Date: 15 Jun 2002 13:38:20 -0400 So, I've been doing a lot of work on another project, whose authors start out every file with: /* -*- Mode: C; tab-width: 8 -*- */ Now, personally, I find this irritating in the extreme. If I nest about four blocks, with a long function name or two, the lines begin to wrap very quickly. One thing I do like about the GNU Coding style is that it says to perform indentation by 2 columns. Unfortunately, believe it or not, Emacs gives me no way to deal with this. You may say, "You can just change tab-width'", but in fact I can't. If I set tab-width' to 2, then everything shrinks nicely to the left. However, I can't just hit TAB anymore to do indentation, because CC mode decides it has to insert *four* tabs in order to make up to the c-basic-offset' value of 8 Now, your next response might be, "Why can't you just set *both* c-basic-offset and tab-width to 2"? And the answer is because that can change the buffer's representation on disk. if (warn) { msg = g_strdup_printf (_("Error while reading file %s:\n%s"), file_name, g_strerror (errno)); If I hit TAB on the last line while c-basic-offset' and tab-width' are both 8, everything is fine. However, If I set them both to 2, then hit TAB, CC mode will insert a bunch of tab characters to try to line it up with the end of function name, which is wrong. Really, I don't want to change the representation on disk at all. I think this problem came about because packages started using tab-width' to convert between actual TAB and space characters. According to its docstring, it is only for display purposes, but CC mode and functions like tabify' use it for other purposes. So I finally got fed up enough with this situation to write the following patch. Given that the tab/space problem has plagued programmers for decades, one would have every right to be surprised if this patch could make things Just Work the way each person wants it to. And indeed, there is a disadvantage: If I keep the (awful) settings of c-basic-offset' and tab-width' => 8, which I must do in order to prevent spurious conflicts and bloated patches, but I set display-tab-width' => 2, then in the above situation, the parameters no longer line up with the function name (in display terms). But I'm willing to live with that disadvantage, in order to get much less line wrapping. Another solution we should pursue is giving some way to tell CC mode to *only* insert tabs when performing indentation. |
| csua.com/?entry=12521 emacs has been the best thing I ever did in my 10 years as an emacs user. especially when I want to format my code, I have to hit space so manytimes. The best practice is to have everyone working on the same file agree on the tab space. It still lets you hit the TAB key to indent, but it insert spaces instead of tabs to the buffer. One used to be able to hit the del button and a tab is erased, now one has to keep hitting space depending how deep the code is at. All the time wasted on hitting the spacebar or the backspace while coding can't be efficient. Just simply agree on the tab space, one setting and everyone is happy to use their own editor of choice. You don't have to "keep hitting space" either, if you have something like the mode-dependent indents in emacs. Spaces are the common denominator, asking for tabs is asking for special arrangement. In many default tools, and printers, tab widths default to 8 which is ugly, especially when spaces get mixed with tabs. tabs are annoying at best to get right, spaces are a no-brainer and always work. Just hope the editor you use lets you substitute the right number of spaces for a tab. if you want to drive a scooter on the freeway and complain about how everyone is going so fast, well... |
| www.jwz.org/doc/tabs-vs-spaces.html I think a big part of these interminable arguments about tabs is based on people using the same words to mean different things. In the following, Im trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects. People care vehemently about a few different things: When reading code, and when theyre done writing new code, they care about how many screen columns by which the code tends to indent when a new scope or sexpr, or whatever opens. When there is some random file on disk that contains ASCII byte 9, the TAB character, they care about how their software reacts to that byte, display-wise. When writing code, they care about what happens when they press the TAB key on their keyboard. Note that I make a distinction between the TAB character which is a byte which can occur in a disk file and the TAB key which is that plastic bump on your keyboard, which when hit causes your computer to do something. As to point 1: A lot of people like that distance to be two columns, and a lot of people like that distance to be four columns, and a smaller number of people like to have somewhat more complicated and context- dependent rules than that. On defaultly-configured Unix systems, and on ancient dumb terminals and teletypes, the tradition has been for the TAB character to mean move to the right until the current column is a multiple of 8. As it happens, this is how Netscape interprets TAB inside <PRE> as well. This is also the default in the two most popular Unix editors, Emacs and vi. In many Windows and Mac editors, the default interpretation is the same, except that multiples of 4 are used instead of multiples of 8. However, some people configure vi to make TAB be mod-2 instead of mod-4 see below. With these three interpretations, the ASCII TAB character is essentially being used as a compression mechanism, to make sequences of SPACE-characters take up less room in the file. Both Emacs and vi are customizable about the number of columns used. Unix terminals and shell-windows are usually customizable away from their default of 8, but sometimes not, and often its difficult. A third interpretation is for the ASCII TAB character to mean indent to the next tab stop, where the tab stops are set arbitrarily: they might not necessarily be equally distanced from each other. On the Mac, BBedit defaults to 4-column tabs, but the tabstops can be set anywhere. It also has entab and detab commands, for converting from spaces to tabs and vice versa just like Emacss M-x tabify and M-x untabify . As to point 3, the tab key: this is an editor user interface issue. Some editors like vi treat TAB as being exactly like X, Y, and Z: when you type it, it gets inserted into the file, end of story. With editors like this, the interpretation of point 2 is what really matters: since TAB is just a self-inserting character, the way that one changes the semantics of hitting the TAB key on the keyboard is by changing the semantics of the display of the TAB character. Some editors like Emacs treat TAB as being a command which means indent this line. And by indent, it means, cause the first non-whitespace character on this line to occur at column N . To editors like this, it doesnt matter much what kind of interpretation is assigned to point 2: the TAB character in a file could be interpreted as being mod-2 columns, mod-4 columns, or mod-8 columns. The only thing that matters is that the editor realize which interpretation of the TAB character is being used, so that it knows how to properly put the file characters on the screen. The decisions of how many characters by which an expression should be indented point 1 and of how those columns should be encoded in the file using the TAB character point 2 are completely orthogonal. My opinion is that the best way to solve the technical issues is to mandate that the ASCII 9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk. That simplifies matters greatly, by separating the technical issues of 2 and 3 from the religious issue of 1. As a data point, my personal setup is the same as the default Emacs configuration: the TAB character is interpreted as mod-8 indentation; |