From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20853 invoked by alias); 13 Oct 2016 10:14:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39627 Received: (qmail 19867 invoked from network); 13 Oct 2016 10:14:00 -0000 X-Qmail-Scanner-Diagnostics: from nm8-vm1.bullet.mail.ir2.yahoo.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(212.82.96.135):SA:0(0.0/5.0):. Processed in 0.163027 secs); 13 Oct 2016 10:14:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 212.82.96.135 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1476353313; bh=riA80SIvg6J0LadCrTyLmdy6cSUDRnjNS/94lzfWbkg=; h=cc:In-reply-to:From:References:To:Subject:Date:From:Subject; b=bSWW0DGR5oc02zzBIVa/jrDZkUXN9h/a1tYSJCziActeo45RhZ+mNIhdgVKwi/h+vxnEhTyVZ6smIAwV3nxZi/hJcLd3EGFUP985gtXPS+NCBi0lLsUr1/pDmh6ZwB1ND2pAh6v3cHzrUluZiNDap5VnnG1UMxUWEp16uGVWtRo5zQIaXrhhKI97E8aPTArsy45mdBPzsvYNokLeV2NnLzcS0Nu9lA4Bwdf6m5ksbGa413Rv7vzwNLElA4bt1ldH/c+FUCAGVCRkt3Z2c+2PCxzwOKiWTK6W+eZlqhtrOJmfcl1uTN6eD6C077uireYxTcGXN6+Y9iA2SXKwVTamlw== X-Yahoo-Newman-Id: 184953.59458.bm@smtp104.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: P.a3FBwVM1mgZg1Q5W_Cw_QLyE6aqlVdTO4n06t7oJ1ruRe yt6QCSOKgjohQfUjw9QQTfCG1K3k5Pfc_M9mTqwVm2UWaSYvN1VV.RwGJu2K LEQLP2gWYuq4z6sh51DrLo3WqRww0G8Ko0g6PFJCHRCnfcAtiRCglDo__CD3 sa.zmT4ZgqRfk82NieVvdOylhK3PuTVROGEdtPh.tpgTFIrQ2mUyXN6gb_Uj 4XxultZAxH.BMuemPMMTYsxu.gIzEKAU2spQWWHXSKWTb3IrCcTkgK4ZkMLj PBNOItyrB3qQQggs79.64Nr0P0X4Oeifzzx4kUZLObnQhMtA35OOVqYj5uz. _eBAuW8wg6CS9VB7o91s6buE_eVUoXyh7mYJ3bSpzBkzVeS1lenoiX.phn5Q PeP8mLYELEfakktrs0gzpPMiwNziAeVjAfTaUxlGBjhBUIHjXqwVmOxwdtm9 t0qZjyPLH_iRLCEMFS.z7qEzECqDoQghXvn01k_Km3swtNn3gY_MTjsRYw_u tPLa1nnOU6bk1nK4motgo796kCY3bQhHrknQOqgNYeU8- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- cc: zsh-workers@zsh.org In-reply-to: From: Oliver Kiddle References: <20161011212150.GA24484@fujitsu.shahaf.local2> <20161012000249.GA32367@fujitsu.shahaf.local2> <20161012003606.GB32367@fujitsu.shahaf.local2> To: Guilherme Salazar Subject: Re: zsh make(1) completion on FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10085.1476353312.1@hydra.kiddle.eu> Date: Thu, 13 Oct 2016 12:08:32 +0200 Message-ID: <10086.1476353312@hydra.kiddle.eu> 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