start allow backspacing over the start of insert; CTRL-W and CTRL-U
stop once at the start of insert.
nostop like start, except CTRL-W and CTRL-U do not stop at the start of
insert.
When the value is empty, Vi compatible backspacing is used, none of
the ways mentioned for the items above are possible.
*'backup'* *'bk'* *'nobackup'* *'nobk'*
'backup' 'bk' boolean (default off)
global
Make a backup before overwriting a file. Leave it around after the
file has been successfully written. If you do not want to keep the
backup file, but you do want a backup while the file is being
written, reset this option and set the 'writebackup' option (this is
the default). If you do not want a backup file at all reset both
options (use this if your file system is almost full). See the
|backup-table| for more explanations.
When the 'backupskip' pattern matches, a backup is not made anyway.
When 'patchmode' is set, the backup may be renamed to become the
oldest version of a file.
*'backupcopy'* *'bkc'*
'backupcopy' 'bkc' string (default "auto")
global or local to buffer |global-local|
When writing a file and a backup is made, this option tells how it's
done. This is a comma-separated list of words.
The main values are:
"yes" make a copy of the file and overwrite the original one
"no" rename the file and write a new one
"auto" one of the previous, what works best
Extra values that can be combined with the ones above are:
"breaksymlink" always break symlinks when writing
"breakhardlink" always break hardlinks when writing
Making a copy and overwriting the original file:
- Takes extra time to copy the file.
+ When the file has special attributes, is a (hard/symbolic) link or
has a resource fork, all this is preserved.
- When the file is a link the backup will have the name of the link,
not of the real file.
Renaming the file and writing a new one:
+ It's fast.
- Sometimes not all attributes of the file can be copied to the new
file.
- When the file is a link the new file will not be a link.
The "auto" value is the middle way: When Vim sees that renaming the
file is possible without side effects (the attributes can be passed on
and the file is not a link) that is used. When problems are expected,
a copy will be made.
The "breaksymlink" and "breakhardlink" values can be used in
combination with any of "yes", "no" and "auto". When included, they
force Vim to always break either symbolic or hard links by doing
exactly what the "no" option does, renaming the original file to
become the backup and writing a new file in its place. This can be
useful for example in source trees where all the files are symbolic or
hard links and any changes should stay in the local source tree, not
be propagated back to the original source.
*crontab*
One situation where "no" and "auto" will cause problems: A program
that opens a file, invokes Vim to edit that file, and then tests if
the open file was changed (through the file descriptor) will check the
backup file instead of the newly created file. "crontab -e" is an
example, as are several |file-watcher| daemons like inotify. In that
case you probably want to switch this option.
When a copy is made, the original file is truncated and then filled
with the new text. This means that protection bits, owner and
symbolic links of the original file are unmodified. The backup file,
however, is a new file, owned by the user who edited the file. The
group of the backup is set to the group of the original file. If this
fails, the protection bits for the group are made the same as for
others.
When the file is renamed, this is the other way around: The backup has
the same attributes of the original file, and the newly written file
is owned by the current user. When the file was a (hard/symbolic)
link, the new file will not! That's why the "auto" value doesn't
rename when the file is a link. The owner and group