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-Qmail-Scanner-Diagnostics: from hermes.apache.org 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(140.211.11.3):SA:0(-1.3/5.0):. Processed in 0.112419 secs); 22 Jul 2016 06:23:07 -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=-1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at apache.org does not designate permitted sender hosts) Date: Fri, 22 Jul 2016 06:22:59 +0000 From: Daniel Shahaf To: Oliver Kiddle Cc: zsh-workers@zsh.org Subject: Re: [PATCH v2] Re: [PATCH] _add-zle-hook-widget: New completion. Message-ID: <20160722062259.GB3457@tarsus.local2> References: <160716185103.ZM5258@torch.brasslantern.com> <1468767614-9635-1-git-send-email-danielsh@tarsus.local2> <91351.1468835277@hydra.kiddle.eu> <20160720065421.GE28939@tarsus.local2> <22468.1469114906@hydra.kiddle.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22468.1469114906@hydra.kiddle.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Seq: zsh-workers 38910 Oliver Kiddle wrote on Thu, Jul 21, 2016 at 17:28:26 +0200: > Daniel Shahaf wrote: > > This is just a coding style question; there are arguments for both > > sides. What's the house style for completion functions, to have > > explicit 'return' statements or not to have them? > > > > I'll make the v3 iteration use the house style, whatever it is. > > I don't claim to be the arbiter on whatever the house style is. > Most early completion code was written by Sven and I've tried to > be consistent with that. Looking over some examples now, he didn't > appear to use superfluous return statements. > > In the end, it is more important to get the return status right, > however. I've decided to let PEP 20 be the arbiter and kept the return statements. > Furthermore, while checking that this wasn't intentional I noticed > a couple of functions that use _normal where _default was meant. _default appears to be undocumented. Cheers, Daniel