Differences between version 13 and predecessor to the previous major change of TabStops.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 13 | Last edited on Sunday, July 23, 2006 6:48:36 pm | by AristotlePagaltzis | Revert |
| Older page: | version 12 | Last edited on Thursday, March 23, 2006 2:29:05 pm | by IanMcDonald | Revert |
@@ -1,28 +1,30 @@
!!! PerryLorier and his ReligiousWar
-Tabs should be 8 characters and no correspondance shall be entered into. While that's stupidly wide, at least it's a standard.
There is absolutely nothing worse than opening a file and having it look like it was formatted by a two year old chimpanzee on crack.
+Tabs should be 8 characters and no correspondance shall be entered into. While that's stupidly wide, at least it's a standard. There is absolutely nothing worse than opening a file and having it look like it was formatted by a two year old chimpanzee on crack.
!! But vim/emacs support mode lines so you can see which tab width you use!
-Except that
-# they
don't agree on the syntax, so you need two sets of modelines, one for each application
-#
grep/patch/diff/sed/lpr/less don't read modelines.
+Except:
+* They
don't agree on the syntax, so you need two sets of modelines, one for each application.
+* <tt>
grep<
/tt>/<tt>
patch<
/tt>/<tt>
diff<
/tt>/<tt>
sed<
/tt>/<tt>
lpr<
/tt>/</tt>
less</tt>
don't read modelines.
-!!You can run things through a preprocessor to convert tabs to the correct number of spaces!
+!! You can run things through a preprocessor to convert tabs to the correct number of spaces!
-A converted diff does not apply as a proper patch anymore. A converted MakeFile bombs out due to a "missing delimiter". A converted __
sendmail.cf__
means no mail is delivered.
+A converted diff does not apply as a proper patch anymore. A converted MakeFile bombs out due to a "missing delimiter". A converted <tt>
sendmail.cf</tt>
means no mail is delivered.
!! You can tell [Vim]/[Emacs]/etc to always expand tabs to spaces
Some people may tell you to do something like
-
:set tabstop=8
- :set shiftwidth=4
+<verbatim>
+
:set tabstop=8
+:set shiftwidth=4
+</verbatim>
in [Vim] (and analogous in [Emacs]). Backspace for unindent doesn't work anymore then. You remove one space, not one tab.
-''Please see [Converting tabs to spaces|http://vim.sourceforge.net/tips/tip.php?tip_id=12] which is a little more optimistic!'' --
Ben Fowler
+''Please see [Converting tabs to spaces|http://vim.sourceforge.net/tips/tip.php?tip_id=12] which is a little more optimistic!'' —
Ben Fowler
!! But they push my code too far to the right
Then your logic is too complicated. Break it into another function to simplify it.
@@ -30,9 +32,10 @@
%%%
The correct answer is to use 8 character tabs. Sure they are wider than they need to be, but they ''work''. Anyone who tries to tell you that tabs should be whatever else they feel like (2? 4? 5? 6?) needs to be shot. Especially if they ever think that their code is going to be viewed by anyone else, so unless you are writing a proprietary program and never planning on giving the code away or ever showing it to anyone, don't change the tab size.
-Of course, if everyone just used python
then it wouldn't matter.
+Of course, if everyone just used [Python]
then it wouldn't matter.
+
!!! Meanwhile, AristotlePagaltzis rests in nirvana
You can use 4 character tabs and feel fine all along. More importantly, so will the people who open your files.
@@ -43,8 +46,19 @@
__ONLY use tabs to indent. %%% ONLY use tabs at the beginning of a line. %%% ONLY use spaces to line up things in the middle of a block.__
Then you can choose your tab width whichever way you like and noone will ever be the wiser from looking at your files.
-
-Have a nice day.
''While this sounds fine, I've never seen it work in practise :( -- PerryLorier''
+
+
+!!! Unbeknownst to many, Nick Gravgaard sets out to solve the problem once and for all
+
+In his [Elastic tabstops | http://nickgravgaard.com/elastictabstops/] article, he puts forth:
+
+> Using spaces to align columns is obviously a kludge, but tabs as they stand now are broken.
+>
+> !! The solution - tabstops that expand or shrink to fit their contents
+>
+> For as long as we continue to define each tabstop as being a multiple of N characters we will never be able to solve this problem satisfactorily. The problem is that we're using tabs and spaces to format text for aesthetic reasons rather than treating them semantically – tabs are for indenting and aligning text, spaces are for separating keywords. The solution then is to redefine how tabs are interpreted by the text editor. Rather than saying that a tab character (a "hard tab") will move the cursor until the cursor's position is a multiple of N characters, we should say that a tab character is a delimiter between table cells in a similar manner to how they're used in tab separated value (TSV) files.
+
+Of course, the question is when (if ever) <tt>grep</tt>/<tt>patch</tt>/<tt>diff</tt>/<tt>sed</tt>/<tt>lpr</tt>/</tt>less</tt> would be taught to follow this approach…
