Taken from share/misc/indent.pro.
Indent does not wrap code to fit into the line width, it only does so
for comments. The 'INDENT OFF' sections and too long lines will be
addressed in a follow-up commit.
No functional change.
With manual corrections afterwards, to compensate for the remaining bugs
in indent.
Without the type definitions in .indent.pro, the opening braces of the
functions kw_name and lexi_alnum would not be at the beginning of the
line.
The variables 'keywords' and 'typenames' were indented using 8 spaces,
even though -di0 was in effect, which should result in a single space,
and -ut was in effect, which should result in a single tab instead of 8
spaces.
The option -eei does not work as advertised, the controlling expressions
are only indented by the normal amount, which easily leads to confusion
as to whether the code belongs to the condition or the following
statement.
One might expect that the code of indent is properly indented according
to its own capabilities, but that's not the case, there are many
deviations.
This indentation profile comes close to the existing code. Maybe someday
indent's own source code can be formatted using this profile, but before
attempting that, its remaining bugs have to be fixed.
Development of indent has essentially stopped somewhere around 1990, as
demonstrated by the wrong formatting of '...' that has only been fixed a
few minutes ago. The '...' is an invention of C90. Indent's parser still
considers '...' as consisting of the 3 tokens period-period-period, but
that's OK since the effect is the same.
Another feature that had been missing for a long time were C99 comments
that span from '//' to the next newline. Before March 2021, these were
parsed as a binary operator, which produced lots of funny side effects.
Since indent's code makes use of several C99 features, as soon as it can
properly indent its own code, the worst of these bugs will have been
fixed.
rillig