If you start editing a shell script and then open a buffer with a C
file, the shiftwidth set by the previous autocommand for the sh file
type would not be reset to the original (global) 8ch. Let's fix this by
explicitly setting the shiftwidth in the C file type autocommand as
well.
We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
Patches are shown on github with a fixed width (no matter how wide the window
is). When line numbers are high (we have some files with 5 digit line numbers),
the diff does not fit, and horizontal scrolling must be used when viewing the
patch. This is super annoying. Let's reduce the width a bit. I think 109 is
still very wide, but at least the github issue should be alleviated.
For all other files leave the line width at 79 as before. This is a good idea
since we generally don't want text files such as catalog files, unit files or
README/NEWS files to be line-broken at 119 since they are regularly browsed on
text terminals.
While we are at it, also add a couple of comments to the various files.
(Note that .editorconfig doesn't carry line-width information, simply because
the specification doesn't know the concept.)
Let's be a bit more precise with the editor configuration and specify a higher fill column of 119. This isn't as emacs'
default of 70, but also not particularly high on today's screens.
While we are at it, also set a couple of other emacs C coding style variables.