controlled by 'tabstop' and is set to eight by default.  Although you can
change it, you quickly run into trouble later.  Other programs won't know what
tabstop value you used.  They probably use the default value of eight, and
your text suddenly looks very different.  Also, most printers use a fixed
tabstop value of eight.  Thus it's best to keep 'tabstop' alone; if you edit a
file which was written with a different tabstop setting, see |25.3| for how
to fix that.
   For indenting lines in a program, using a multiple of eight columns makes
you quickly run into the right border of the window.  Using a single space
doesn't provide enough visual difference.  Many people prefer to use four
spaces, a good compromise.
   Since a tab character at the beginning of a line is visually represented
as eight spaces and you want to use an indent of four spaces, you can't use a
tab character to make your indent.
  To remedy this, `vi` had the 'shiftwidth' option.  When set to 4, on a new
line, pressing <C-t> in Insert mode would indent the line by 4 spaces,
a result impossible to get with the <Tab> key and 'tabstop' set to 8.
 To optimize space, `vi` would also silently remove packs of spaces and replace
them with tab characters.  The following shows what happens pressing <C-t>
a few times.
  A "." stands for a space character and "------->" for a tab character.

	type				result ~
	<C-t>				....
	<C-t><C-t>			------->
	<C-t><C-t><C-t>			------->....

  Similarly pressing <C-d> in Insert mode would decrease the indent.  Hence
with `set tabstop=8 shiftwidth=2` one has

	type				result ~
	<C-t><Tab><C-t>			..----->..
	<C-t><Tab><C-t><C-d>		------->

  A third option that one could set in `vi` was 'autoindent'.  It copies the
indent level of the previous lines,

	type				result ~
	<Space><Tab>hello		.------>hello
	<Space><Tab>hello<Enter>	.------>hello
					------->

but the new line is produced by optimizing the number of characters used.


JUST SPACES

But separating tab stops with 8 columns was not universal: IBM had a standard
at 10 columns, and today some Go developers write code with `tabstop=4`.  Every
time text is displayed with a different 'tabstop' value, it risks misaligning
the text, especially once the file is shared and opened on another machine.
  In the meantime, computers got much better and the few octets saved by using
tabs were no longer making any real difference.  It became possible to use
only spaces and thus guarantee the same resulting text everywhere.  But using
only spaces was impossible in `vi` without sacrificing features.  Remember that
'autoindent' would systematically try to input a tab character when it could.
  Vim 4.0 made working with only spaces as convenient as working only with
tabs (or a mix of tabs and spaces), by introducing the 'expandtab' option.
When set, Vim will replace any horizontal tab character it would normally
insert with an equivalent number of spaces, to end up with the same visual
effect. <BS> would continue to remove only one character at a time.

	type				result ~
	<Tab>				........
	<Tab><BS>			.......


CHANGING TABS IN SPACES (AND BACK)

Setting 'expandtab' does not immediately affect existing tab characters.  In
order to purge a file from all its horizontal tab characters, Vim 5.3
introduced the |:retab| command.  Use these commands: >

	:set expandtab
	:retab

This is a little bit dangerous, because it can also change tabs inside a
string.  To check if these exist, you could use this: >

	/"[^"\t]*\t[^"]*"

It's recommended not to use actual tab characters inside a string.  Replace
them with "\t" to avoid trouble.

  The other way around works just as well: >

	:set noexpandtab
	:retab!


SOFT TAB STOPS

When using only spaces, or a mix of spaces and horizontal tabs, one gets the
unpleasant feeling that the two keys <Tab> and <BS> do not act in mirror, as
they do when using only tab characters.
  Vim 5.4 introduced the 'softtabstop' option.  On top of the (hard) tab stops
used to display