From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11487 invoked by alias); 10 Feb 2016 17:41:30 -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: 37939 Received: (qmail 5661 invoked from network); 10 Feb 2016 17:41:28 -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.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version:content-type; bh=/TZhBZUU78muf73+36T0kZG98NFiw/xUon23TqQ/WCU=; b=jsr7ex7C0Is3zuKFDn+cZf7aNhJJyBnoNNqz37+rsJZseIWS15M2PShZnPHiDfsQ5/ /z2OyrW+2Pp1lR7nHERpYTVvatTPyx5+hXXWfjF8JTKEI9J0rlIB49EeIYUY679cEfB9 C314NpgAkcnQ09YVyvsqhEOX7dxkKZUkbAYukikz3J8QwNt847qbwaToyxLajVh7F/AL 1oPCYqfjy5NJBIGSxNnBDlFXIxThlDfLQy0NCXtSy9H2nBRWgsrgtZXft5oeFvCnlAuY 2B3vmNOwJR3QScXiG6DpI5kb+9X5HgXctYb16jtAHXwCPLQPtb37cUOztdQye5ATOV+Q BciA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=/TZhBZUU78muf73+36T0kZG98NFiw/xUon23TqQ/WCU=; b=UrKyChbogMP6NdzyvOPqNIDiHUOgoM+nu/yXnkzM2gjuYKloRACuYnzGwLcj2ravRt 2D6iuBnhwu7I02BB3q7kR5qX+DtjH96ObjEZv2l1BVfjmNY4Yce9XB0/pa2LH+8GVpqD 8DXMWmiTLTqS65E0I8u0cBm3FCTalcK/eN5l10dsoDKPJbI+eNwHh0Qr774bGEI67vk/ TEhDog49HJiGwhqIHbgQobWHU7gwz7BUEw390DY5CUSZUX7e/Z8J06Ao/Cj7M4iTF958 HE8gicgD/2VkMAzC2D3mu80BZ85w2uZeEyBM3hZZJQVbsEIMuSiLxrtObfQYtrGdHS8z zYdw== X-Gm-Message-State: AG10YOSgQYk/Gfi6G0aPRfEFpDlGT7Y1nxdbE5gTkHnTAhDATuSQIvQi7qQ0rNdJxmSTOQ== X-Received: by 10.98.89.78 with SMTP id n75mr59283011pfb.120.1455126085361; Wed, 10 Feb 2016 09:41:25 -0800 (PST) From: Bart Schaefer Message-Id: <160210094134.ZM2246@torch.brasslantern.com> Date: Wed, 10 Feb 2016 09:41:34 -0800 In-Reply-To: <20160210092324.GA6339@tarsus.local2> Comments: In reply to Daniel Shahaf "Re: min() max() math functions (was: Re: Feature request (@M):# with context matches)" (Feb 10, 9:23am) References: <160130085456.ZM9730__49922.0612728552$1454172936$gmane$org@torch.brasslantern.com> <20160207002212.GC24068@tarsus.local2> <160206170040.ZM1927__13399.3204137825$1454806909$gmane$org@torch.brasslantern.com> <20160209032308.GA20947@tarsus.local2> <160208212222.ZM27970@torch.brasslantern.com> <20160210092324.GA6339@tarsus.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: min() max() math functions (was: Re: Feature request (@M):# with context matches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 10, 9:23am, Daniel Shahaf wrote: } Subject: Re: min() max() math functions (was: Re: Feature request (@M):# w } } Bart Schaefer wrote on Mon, Feb 08, 2016 at 21:22:22 -0800: } > } > emulate zsh -c 'autoload -U zmathfunc' } } Shouldn't this form be used more often? As in, wouldn't using this form } be correct for the majority of autoloadable functions? It has other side-effects which are desirable in the zmathfunc case but may not be in other cases. (Specifically, the stickyness is transitive to functions defined when the autoloaded function runs.) Whether "the majority" of autoloads would benefit, I don't know. Some functions perform a task in a very isolated way, others are intended to preserve the behavior the user's setopts have defined, and it's not possible to readily determine which have the latter intent. } > Although it seems an oversight that you can't combine -u and -M for the } > functions command. } } Would this be easy to add? I took a quick look and decided it wasn't straightforward enough to mess with today. The different interpretation of the argument list for -M makes it complicated to untangle the current implementation. And one can get the same effect by doing autoload mathfunc functions -M mf 0 0 mathfunc in either order (that is, the shell function doesn't have to be defined to link it to a math context name). } (Just another flag in the stub function structure, maybe?) Doesn't even need that. } > Ehh, I'm not sure it's the job of any module's doc to explain what it } > does NOT define, much less to cross-reference zshcontrib. } } Why is it a problem for zshmodules to reference zshcontrib? Should } zmathfunc's documentation be located elsewhere? It's not exactly a problem, more like a bad precedent. E.g. I was careful to have zshcontrib for the *-word-match functions refer to the vim text objects, but I would not reference in the other direction. It should IMO be possible to throw away the zshcontrib manual and still have a complete reference to the "bare" shell. The most obvious counter-argument is that the entire completion system depends on mutually cooperating options, builtins, and shell functions. And the complist module already references the colors autoload, so I should probably just shrug and ignore my sense of propriety.