zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Guilherme Salazar <gmesalazar@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: zsh make(1) completion on FreeBSD
Date: Thu, 13 Oct 2016 12:08:32 +0200	[thread overview]
Message-ID: <10086.1476353312@hydra.kiddle.eu> (raw)
In-Reply-To: <CA+Hmt2jYkzTZBohoF3MpZ8P+MXyLJWpfAi7Mc1NOfBj3W_Zjwg@mail.gmail.com>

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


  reply	other threads:[~2016-10-13 10:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06  2:56 Guilherme Salazar
2016-10-11 21:21 ` Daniel Shahaf
2016-10-11 23:27   ` Guilherme Salazar
2016-10-12  0:02     ` Daniel Shahaf
2016-10-12  0:24       ` Guilherme Salazar
2016-10-12  0:36         ` Daniel Shahaf
2016-10-12  1:14           ` Guilherme Salazar
2016-10-12  3:27             ` Guilherme Salazar
2016-10-13 10:08               ` Oliver Kiddle [this message]
2016-10-14  6:10                 ` Daniel Shahaf
2016-10-16 16:34             ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10086.1476353312@hydra.kiddle.eu \
    --to=okiddle@yahoo.co.uk \
    --cc=gmesalazar@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).