- verily carefree
- Apr 5, 2014
-
|
I press the tab button
|
#
?
Jun 26, 2015 00:53
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
#
?
May 4, 2024 11:25
|
|
- PleasingFungus
- Oct 10, 2012
-
idiot asshole bitch who should fuck off
|
All the true hard tabsmen took one look at those hambugger buttons and turned 360 degrees outta that poll
it's not a poll.
|
#
?
Jun 26, 2015 01:40
|
|
- echinopsis
- Apr 13, 2004
-
by Fluffdaddy
|
it was jsut a diet drink. unique flavour
|
#
?
Jun 26, 2015 07:03
|
|
- JewKiller 3000
- Nov 28, 2006
-
by Lowtax
|
i've had tab. it was pretty good. i'd drink it again
|
#
?
Jun 26, 2015 09:18
|
|
- dimebag dinkman
- Feb 20, 2003
-
|
i only drink tab clear, also known as "the soft tab"
|
#
?
Jun 26, 2015 11:19
|
|
- echinopsis
- Apr 13, 2004
-
by Fluffdaddy
|
she called it the soft tab but you knew it by the name you called it as a child "spoof"
|
#
?
Jun 26, 2015 12:15
|
|
- poty
- Jun 21, 2008
-
虹はどこで終わるのですか? あなたの魂の中で、または地平線で?
|
all this computer hacking is making me thirsty
lol
|
#
?
Jun 30, 2015 16:51
|
|
- leftist heap
- Feb 28, 2013
-
-
Fun Shoe
|
i use soft tabs now because that seems to be the way the programer winds are blowin but i never really got the hate for hard tabs. like, i think it makes sense on a logical level. hard tab says "hey, this line should be indented a specified number of units, how you want to render that, two spaces, 4 spaces, a combination whatever it's all good to me." seems p. good to me.
|
#
?
Jun 30, 2015 19:35
|
|
- Baxate
- Feb 1, 2011
-
|
i just learned that ruby yaml files don't allow hard tabs and it makes me unreasonably angry!!
|
#
?
Jul 14, 2015 18:20
|
|
- pram
- Jun 10, 2001
-
|
uhh does any yaml file (tabs are poo poo idiot)
|
#
?
Jul 14, 2015 18:22
|
|
- Shaggar
- Apr 26, 2006
-
|
i use soft tabs now because that seems to be the way the programer winds are blowin but i never really got the hate for hard tabs. like, i think it makes sense on a logical level. hard tab says "hey, this line should be indented a specified number of units, how you want to render that, two spaces, 4 spaces, a combination whatever it's all good to me." seems p. good to me.
right. anyone who doesn't understand the fundamental superiority of hard tabs should not be programming.
|
#
?
Jul 14, 2015 18:30
|
|
- Share Bear
- Apr 27, 2004
-
|
just do whatever the lead nerd chose at your job and get on with your lives
|
#
?
Jul 14, 2015 19:50
|
|
- karms
- Jan 22, 2006
-
by Nyc_Tattoo
-
Yam Slacker
|
soft tabs are the best because it allows me to janitor my code with even more sperg
|
#
?
Jul 14, 2015 22:16
|
|
- Farmer Crack-Ass
- Jan 2, 2001
-
this is me posting irl
|
people go apeshit when something looks different on another computer than it does on their own computer
work just bought one of the devs a 27" imac b/c the owner thought the websites didn't look good when he maximized them on his 27" mac display
|
#
?
Jul 17, 2015 06:13
|
|
- Moist von Lipwig
- Oct 28, 2006
-
by FactsAreUseless
-
Tortured By Flan
|
Lol if you don't manually type out \t all over the place
aaaaaaaaaaaaaaaaaaaaaaa
|
#
?
Jul 17, 2015 06:30
|
|
- BONGHITZ
- Jan 1, 1970
-
|
I don't see the problem.
|
#
?
Jul 19, 2015 00:35
|
|
- cowboy beepboop
- Feb 24, 2001
-
|
work just bought one of the devs a 27" imac b/c the owner thought the websites didn't look good when he maximized them on his 27" mac display
nice going to try and wrangle one too thanks op
|
#
?
Jul 19, 2015 01:19
|
|
- Farmer Crack-Ass
- Jan 2, 2001
-
this is me posting irl
|
nice going to try and wrangle one too thanks op
no problem man best of luck
|
#
?
Jul 19, 2015 01:36
|
|
- Linguica
- Jul 13, 2000
-
You're already dead
|
The last time the tabs-versus-spaces argument flared up in my presence, I wrote this. Gasoline for the fire? Maybe.
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, I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects.
Anyway. People care (vehemently) about a few different things:
When reading code, and when they're 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.
As to point #2, the tab character: there is a lot of history here.
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 it's 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. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.
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 Emacs's ``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. (It then gets displayed on the screen according to point #2.)
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 doesn't 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.
So, the real religious war here is point #1.
Points #2 and #3 are technical issues about interoperability.
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; but my code is indented by mod-2.
I prefer this setup, but I don't care deeply about it.
I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read.
In Emacs, to set the mod-N indentation used when you hit the TAB key, do this:
(setq c-basic-offset 2)
or (setq c-basic-offset 4)
To cause the TAB file-character to be interpreted as mod-N indentation, do this:
(setq tab-width 4)
or (setq tab-width 8)
To cause TAB characters to not be used in the file for compression, and for only spaces to be used, do this:
(setq indent-tabs-mode nil)
You can also do this stuff on a per-file basis. The very first line of a file can contain a comment which contains variable settings. For the XP code in the client, you'll see many files that begin with
/* -*- Mode: C; tab-width: 4 -*- */
The stuff between -*-, on the very first line of the file, is interpreted as a list of file-local variable/value pairs. A hairier example:
/* -*- mode: java; c-basic-offset: 2; indent-tabs-mode: nil -*- */
If you have different groups of people with different customs, the presence of these kinds of explicit settings are really handy.
I believe vi has a mechanism for doing this sort of thing too, but I don't know how it works.
To keep myself honest (that is, to ensure that no tabs ever end up in source files that I am editing) I also do this in my .emacs file:
(defun java-mode-untabify ()
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[ \t]+$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))
(if (search-forward "\t" nil t)
(untabify (1- (point)) (point-max))))
nil)
(add-hook 'java-mode-hook
'(lambda ()
(make-local-variable 'write-contents-hooks)
(add-hook 'write-contents-hooks 'java-mode-untabify)))
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save. This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Here are some details on vi, courtesy of Woody Thrower:
Standard vi interprets the tab key literally, but there are popular vi-derived alternatives that are smarter, like vim. To get vim to interpret tab as an ``indent'' command instead of an insert-a-tab command, do this:
set softtabstop=2
To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-offset), do this:
set shiftwidth=2
To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this:
set tabstop=4
To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this:
set expandtab
In vi (and vim), you can do this stuff on a per-file basis using ``modelines,'' magic comments at the top of the file, similarly to how it works in Emacs:
/* ex: set tabstop=8 expandtab: */
So go forth and untabify!
|
#
?
Jul 19, 2015 01:43
|
|
- Baxate
- Feb 1, 2011
-
|
The last time the tabs-versus-spaces argument flared up in my presence, I wrote this. Gasoline for the fire? Maybe.
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, I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects.
Anyway. People care (vehemently) about a few different things:
When reading code, and when they're 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.
As to point #2, the tab character: there is a lot of history here.
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 it's 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. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.
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 Emacs's ``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. (It then gets displayed on the screen according to point #2.)
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 doesn't 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.
So, the real religious war here is point #1.
Points #2 and #3 are technical issues about interoperability.
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; but my code is indented by mod-2.
I prefer this setup, but I don't care deeply about it.
I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read.
In Emacs, to set the mod-N indentation used when you hit the TAB key, do this:
(setq c-basic-offset 2)
or (setq c-basic-offset 4)
To cause the TAB file-character to be interpreted as mod-N indentation, do this:
(setq tab-width 4)
or (setq tab-width 8)
To cause TAB characters to not be used in the file for compression, and for only spaces to be used, do this:
(setq indent-tabs-mode nil)
You can also do this stuff on a per-file basis. The very first line of a file can contain a comment which contains variable settings. For the XP code in the client, you'll see many files that begin with
/* -*- Mode: C; tab-width: 4 -*- */
The stuff between -*-, on the very first line of the file, is interpreted as a list of file-local variable/value pairs. A hairier example:
/* -*- mode: java; c-basic-offset: 2; indent-tabs-mode: nil -*- */
If you have different groups of people with different customs, the presence of these kinds of explicit settings are really handy.
I believe vi has a mechanism for doing this sort of thing too, but I don't know how it works.
To keep myself honest (that is, to ensure that no tabs ever end up in source files that I am editing) I also do this in my .emacs file:
(defun java-mode-untabify ()
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[ \t]+$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))
(if (search-forward "\t" nil t)
(untabify (1- (point)) (point-max))))
nil)
(add-hook 'java-mode-hook
'(lambda ()
(make-local-variable 'write-contents-hooks)
(add-hook 'write-contents-hooks 'java-mode-untabify)))
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save. This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Here are some details on vi, courtesy of Woody Thrower:
Standard vi interprets the tab key literally, but there are popular vi-derived alternatives that are smarter, like vim. To get vim to interpret tab as an ``indent'' command instead of an insert-a-tab command, do this:
set softtabstop=2
To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-offset), do this:
set shiftwidth=2
To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this:
set tabstop=4
To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this:
set expandtab
In vi (and vim), you can do this stuff on a per-file basis using ``modelines,'' magic comments at the top of the file, similarly to how it works in Emacs:
/* ex: set tabstop=8 expandtab: */
So go forth and untabify!
gently caress you for making me read this
|
#
?
Jul 19, 2015 01:57
|
|
- maniacdevnull
- Apr 18, 2007
-
FOUR CUBIC FRAMES
DISPROVES SOFT G GOD
YOU ARE EDUCATED STUPID
|
The last time the tabs-versus-spaces argument flared up in my presence, I wrote this. Gasoline for the fire? Maybe.
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, I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects.
Anyway. People care (vehemently) about a few different things:
When reading code, and when they're 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.
As to point #2, the tab character: there is a lot of history here.
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 it's 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. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.
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 Emacs's ``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. (It then gets displayed on the screen according to point #2.)
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 doesn't 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.
So, the real religious war here is point #1.
Points #2 and #3 are technical issues about interoperability.
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; but my code is indented by mod-2.
I prefer this setup, but I don't care deeply about it.
I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read.
In Emacs, to set the mod-N indentation used when you hit the TAB key, do this:
(setq c-basic-offset 2)
or (setq c-basic-offset 4)
To cause the TAB file-character to be interpreted as mod-N indentation, do this:
(setq tab-width 4)
or (setq tab-width 8)
To cause TAB characters to not be used in the file for compression, and for only spaces to be used, do this:
(setq indent-tabs-mode nil)
You can also do this stuff on a per-file basis. The very first line of a file can contain a comment which contains variable settings. For the XP code in the client, you'll see many files that begin with
/* -*- Mode: C; tab-width: 4 -*- */
The stuff between -*-, on the very first line of the file, is interpreted as a list of file-local variable/value pairs. A hairier example:
/* -*- mode: java; c-basic-offset: 2; indent-tabs-mode: nil -*- */
If you have different groups of people with different customs, the presence of these kinds of explicit settings are really handy.
I believe vi has a mechanism for doing this sort of thing too, but I don't know how it works.
To keep myself honest (that is, to ensure that no tabs ever end up in source files that I am editing) I also do this in my .emacs file:
(defun java-mode-untabify ()
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[ \t]+$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))
(if (search-forward "\t" nil t)
(untabify (1- (point)) (point-max))))
nil)
(add-hook 'java-mode-hook
'(lambda ()
(make-local-variable 'write-contents-hooks)
(add-hook 'write-contents-hooks 'java-mode-untabify)))
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save. This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Here are some details on vi, courtesy of Woody Thrower:
Standard vi interprets the tab key literally, but there are popular vi-derived alternatives that are smarter, like vim. To get vim to interpret tab as an ``indent'' command instead of an insert-a-tab command, do this:
set softtabstop=2
To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-offset), do this:
set shiftwidth=2
To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this:
set tabstop=4
To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this:
set expandtab
In vi (and vim), you can do this stuff on a per-file basis using ``modelines,'' magic comments at the top of the file, similarly to how it works in Emacs:
/* ex: set tabstop=8 expandtab: */
So go forth and untabify!
did
not
read
at
all
gently caress you
|
#
?
Jul 19, 2015 02:28
|
|
- bobbilljim
- May 29, 2013
-
this christmas feels like the very first christmas to me
|
The last time the tabs-versus-spaces argument flared up in my presence, I wrote this. Gasoline for the fire? Maybe.
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, I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects.
Anyway. People care (vehemently) about a few different things:
When reading code, and when they're 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.
As to point #2, the tab character: there is a lot of history here.
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 it's 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. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.
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 Emacs's ``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. (It then gets displayed on the screen according to point #2.)
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 doesn't 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.
So, the real religious war here is point #1.
Points #2 and #3 are technical issues about interoperability.
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; but my code is indented by mod-2.
I prefer this setup, but I don't care deeply about it.
I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read.
In Emacs, to set the mod-N indentation used when you hit the TAB key, do this:
(setq c-basic-offset 2)
or (setq c-basic-offset 4)
To cause the TAB file-character to be interpreted as mod-N indentation, do this:
(setq tab-width 4)
or (setq tab-width 8)
To cause TAB characters to not be used in the file for compression, and for only spaces to be used, do this:
(setq indent-tabs-mode nil)
You can also do this stuff on a per-file basis. The very first line of a file can contain a comment which contains variable settings. For the XP code in the client, you'll see many files that begin with
/* -*- Mode: C; tab-width: 4 -*- */
The stuff between -*-, on the very first line of the file, is interpreted as a list of file-local variable/value pairs. A hairier example:
/* -*- mode: java; c-basic-offset: 2; indent-tabs-mode: nil -*- */
If you have different groups of people with different customs, the presence of these kinds of explicit settings are really handy.
I believe vi has a mechanism for doing this sort of thing too, but I don't know how it works.
To keep myself honest (that is, to ensure that no tabs ever end up in source files that I am editing) I also do this in my .emacs file:
(defun java-mode-untabify ()
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[ \t]+$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))
(if (search-forward "\t" nil t)
(untabify (1- (point)) (point-max))))
nil)
(add-hook 'java-mode-hook
'(lambda ()
(make-local-variable 'write-contents-hooks)
(add-hook 'write-contents-hooks 'java-mode-untabify)))
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save. This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Here are some details on vi, courtesy of Woody Thrower:
Standard vi interprets the tab key literally, but there are popular vi-derived alternatives that are smarter, like vim. To get vim to interpret tab as an ``indent'' command instead of an insert-a-tab command, do this:
set softtabstop=2
To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-offset), do this:
set shiftwidth=2
To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this:
set tabstop=4
To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this:
set expandtab
In vi (and vim), you can do this stuff on a per-file basis using ``modelines,'' magic comments at the top of the file, similarly to how it works in Emacs:
/* ex: set tabstop=8 expandtab: */
So go forth and untabify!
didn't read, lol
|
#
?
Jul 19, 2015 22:19
|
|
- Hammerite
- Mar 9, 2007
-
And you don't remember what I said here, either, but it was pompous and stupid.
-
Jade Ear Joe
|
doft tabs are extremely Win
|
#
?
Jul 20, 2015 00:32
|
|
- Panty Saluter
- Jan 17, 2004
-
Making learning fun!
|
is that john c mcginley
|
#
?
Jul 20, 2015 22:47
|
|
- Farmer Crack-Ass
- Jan 2, 2001
-
this is me posting irl
|
"robust" is an amusing adjective
|
#
?
Jul 20, 2015 23:26
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
#
?
May 4, 2024 11:25
|
|
- Mozi
- Apr 4, 2004
-
Forms change so fast
Time is moving past
Memory is smoke
Gonna get wider when I die
-
Nap Ghost
|
The last time the tabs-versus-spaces argument flared up in my presence, I wrote this. Gasoline for the fire? Maybe.
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, I'm trying to avoid espousing my personal religion here, I just thought it would be good to try and explain the various sects.
Anyway. People care (vehemently) about a few different things:
When reading code, and when they're 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.
As to point #2, the tab character: there is a lot of history here.
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 it's 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. Most word processors can do this; Emacs can do this. I don't think vi can do this, but I'm not sure.
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 Emacs's ``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. (It then gets displayed on the screen according to point #2.)
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 doesn't 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.
So, the real religious war here is point #1.
Points #2 and #3 are technical issues about interoperability.
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; but my code is indented by mod-2.
I prefer this setup, but I don't care deeply about it.
I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read.
In Emacs, to set the mod-N indentation used when you hit the TAB key, do this:
(setq c-basic-offset 2)
or (setq c-basic-offset 4)
To cause the TAB file-character to be interpreted as mod-N indentation, do this:
(setq tab-width 4)
or (setq tab-width 8)
To cause TAB characters to not be used in the file for compression, and for only spaces to be used, do this:
(setq indent-tabs-mode nil)
You can also do this stuff on a per-file basis. The very first line of a file can contain a comment which contains variable settings. For the XP code in the client, you'll see many files that begin with
/* -*- Mode: C; tab-width: 4 -*- */
The stuff between -*-, on the very first line of the file, is interpreted as a list of file-local variable/value pairs. A hairier example:
/* -*- mode: java; c-basic-offset: 2; indent-tabs-mode: nil -*- */
If you have different groups of people with different customs, the presence of these kinds of explicit settings are really handy.
I believe vi has a mechanism for doing this sort of thing too, but I don't know how it works.
To keep myself honest (that is, to ensure that no tabs ever end up in source files that I am editing) I also do this in my .emacs file:
(defun java-mode-untabify ()
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[ \t]+$" nil t)
(delete-region (match-beginning 0) (match-end 0)))
(goto-char (point-min))
(if (search-forward "\t" nil t)
(untabify (1- (point)) (point-max))))
nil)
(add-hook 'java-mode-hook
'(lambda ()
(make-local-variable 'write-contents-hooks)
(add-hook 'write-contents-hooks 'java-mode-untabify)))
That ensures that, even if I happened to insert a literal tab in the file by hand (or if someone else did when editing this file earlier), those tabs get expanded to spaces when I save. This assumes that you never use tabs in places where they are actually significant, like in string or character constants, but I never do that: when it matters that it is a tab, I always use '\t' instead.
Here are some details on vi, courtesy of Woody Thrower:
Standard vi interprets the tab key literally, but there are popular vi-derived alternatives that are smarter, like vim. To get vim to interpret tab as an ``indent'' command instead of an insert-a-tab command, do this:
set softtabstop=2
To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-offset), do this:
set shiftwidth=2
To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this:
set tabstop=4
To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this:
set expandtab
In vi (and vim), you can do this stuff on a per-file basis using ``modelines,'' magic comments at the top of the file, similarly to how it works in Emacs:
/* ex: set tabstop=8 expandtab: */
So go forth and untabify!
iawtp
|
#
?
Jul 21, 2015 02:39
|
|