Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zsh make(1) completion on FreeBSD
Guilherme Salazar wrote:
> By the way, completely unrelated question: I noticed some
> inconsistencies in the use of tabs/spaces for indentation; are there
> conventions for that in the project? If so, are patches fixing it
> welcome?
Coding conventions are mentioned in the following two files
Etc/zsh-development-guide
Etc/completion-style-guide
Theres also a .editorconfig file.
The short version is that for C, it should be 4 spaces for indentation
using tab characters for blocks of 8 spaces. For completion functions,
it should be 2 (but 4 for continuation lines). Some other functions such
as vcs_info use a different convention and I wouldn't change them.
Completions tend to need long lines so short indentation helps avoid
wrapping. .editorconfig also implies tab characters in the completion functions
which I'm not sure is particularly clever.
As for fixing inconsistencies, it depends:
The trouble with patches that only fix indentation is that they can make
it harder to follow git history. git diff and blame do have a -w option
but still.
In the case of completions, I correct the indentation when making
changes that affect many lines. For example, _zfs has capitalised
descriptions so it would be reasonable to reindent it if also
correcting the descriptions to follow the convention of all lowercase:
descriptions appear on most lines.
You could also argue that fixing indentation is harmless if there is
virtually no history of changes to the file anyway - perhaps common
in the case of function that doesn't follow the conventions anyway,
e.g. _gradle has 2 changes, _gnutls has 4, _zfs has 11 which is a
bit more.
Ultimately, updating the functions for new options is more useful.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author