* Re: min() max() math functions (was: Re: Feature request (@M):# with context matches) [not found] ` <20160209032308.GA20947@tarsus.local2> @ 2016-02-09 5:22 ` Bart Schaefer 2016-02-10 9:23 ` Daniel Shahaf 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2016-02-09 5:22 UTC (permalink / raw) To: zsh-workers [>workers] On Feb 9, 3:23am, Daniel Shahaf wrote: } } I said "built-in" but I meant in zsh/mathfunc, with all other math } functions, for consistency. I was talking about zsh/mathfunc, too. } I suppose I could package them as an autoload. Patch below. That's what I was going to suggest, even to the creation of Functions/Math/. } How do I shield zmathfunc against callers that unsetopt functionargzero? Sticky emulation would do it for you. E.g. emulate zsh -c 'autoload -U zmathfunc' Or examine $funcstack[1] instead of $0 (with localoptions noksharrays), although that introduces a dependence on zsh/parameter. } I guess I'll have to drop the the multifuncdef usage altogether? See for example zmv, zcp, zln. Although it seems an oversight that you can't combine -u and -M for the functions command. } +Autoloading tt(zmathfunc) defines the three mathematical functions You do have to both autoload it and run it, like e.g. "colors". Given that, why not have zmathfunc perform "zmodload zsh/mathfunc" too? } +++ b/Doc/Zsh/mod_mathfunc.yo } +The functions tt(min), tt(max), and tt(sum) are defined not in this module } +but in the tt(zmathfunc) autoloadable function 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: min() max() math functions (was: Re: Feature request (@M):# with context matches) 2016-02-09 5:22 ` min() max() math functions (was: Re: Feature request (@M):# with context matches) Bart Schaefer @ 2016-02-10 9:23 ` Daniel Shahaf 2016-02-10 17:41 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Daniel Shahaf @ 2016-02-10 9:23 UTC (permalink / raw) To: zsh-workers; +Cc: Sebastian Gniazdowski Bart Schaefer wrote on Mon, Feb 08, 2016 at 21:22:22 -0800: > On Feb 9, 3:23am, Daniel Shahaf wrote: > } How do I shield zmathfunc against callers that unsetopt functionargzero? > > Sticky emulation would do it for you. E.g. > > emulate zsh -c 'autoload -U zmathfunc' > Good to know. If I'm not mistaken, using this form would also fix the cshjunkiequotes problems Sebastian has been running into. Shouldn't this form be used more often? As in, wouldn't using this form be correct for the majority of autoloadable functions? > Or examine $funcstack[1] instead of $0 (with localoptions noksharrays), > although that introduces a dependence on zsh/parameter. > > } I guess I'll have to drop the the multifuncdef usage altogether? > > See for example zmv, zcp, zln. > I think the path of least resistance is to drop the multifuncdef usage, and not require the user to create symlinks or to have zsh/parameter [although that module is probably ubiquitous?] or to do the autoload specially. > Although it seems an oversight that you can't combine -u and -M for the > functions command. > Would this be easy to add? (Just another flag in the stub function structure, maybe?) I can check later but don't have time to right now. > } +Autoloading tt(zmathfunc) defines the three mathematical functions > > You do have to both autoload it and run it, like e.g. "colors". Indeed. How about: The function tt(zmathfunc) defines the three mathematical functions... > Given that, why not have zmathfunc perform "zmodload zsh/mathfunc" > too? > I don't see a good reason to force users of the autoload to use the module. It's a non-obvious side effect (consider somebody who does 'autoload zmathfunc && zmathfunc && zmodload -F ... zsh/mathfunc') that's not easy for the caller to disable. (But see below) > } +++ b/Doc/Zsh/mod_mathfunc.yo > } +The functions tt(min), tt(max), and tt(sum) are defined not in this module > } +but in the tt(zmathfunc) autoloadable function > > 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. The functionality of zmathfunc is related to that of zsh/mathfunc. The reason they aren't the same thing is due to implementation considerations (we separated functions that can be implemented satisfactorily in shell code from those that must be implemented in C), not due to interface considerations. In fact, that's an argument in favour of making zsh/mathfunc autoload zmathfunc (sic, in this order). Why is it a problem for zshmodules to reference zshcontrib? Should zmathfunc's documentation be located elsewhere? Cheers, Daniel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: min() max() math functions (was: Re: Feature request (@M):# with context matches) 2016-02-10 9:23 ` Daniel Shahaf @ 2016-02-10 17:41 ` Bart Schaefer 2016-02-14 14:33 ` Daniel Shahaf 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2016-02-10 17:41 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: min() max() math functions (was: Re: Feature request (@M):# with context matches) 2016-02-10 17:41 ` Bart Schaefer @ 2016-02-14 14:33 ` Daniel Shahaf 0 siblings, 0 replies; 4+ messages in thread From: Daniel Shahaf @ 2016-02-14 14:33 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote on Wed, Feb 10, 2016 at 09:41:34 -0800: > On Feb 10, 9:23am, Daniel Shahaf wrote: > } > 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. I don't think it's a problem for other manuals to provide pointers to functionality in zshcontrib. It might be a problem if some core functionality _depended_ on zshcontrib functionality, but that's not the case here. In the interest of going forward, I'll commit what I have so far, but we can tweak the docs in further commits if needed. Cheers, Daniel Interdiff relative to users/21256: diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo index 11678e5..f8754fb 100644 --- a/Doc/Zsh/contrib.yo +++ b/Doc/Zsh/contrib.yo @@ -3804,7 +3804,7 @@ xitem(tt(min+LPAR())var(arg)tt(, ...+RPAR())) xitem(tt(max+LPAR())var(arg)tt(, ...+RPAR())) xitem(tt(sum+LPAR())var(arg)tt(, ...+RPAR())) item(tt(zmathfunc))( -Autoloading tt(zmathfunc) defines the three mathematical functions +The function tt(zmathfunc) defines the three mathematical functions tt(min), tt(max), and tt(sum). The functions tt(min) and tt(max) take one or more arguments. The function tt(sum) takes zero or more arguments. Arguments can be of different types (ints and floats). diff --git a/Functions/Math/zmathfunc b/Functions/Math/zmathfunc index 17d3336..4ff4070 100644 --- a/Functions/Math/zmathfunc +++ b/Functions/Math/zmathfunc @@ -1,21 +1,26 @@ #autoload -setopt localoptions multifuncdef +zsh_math_func_min() { + local result=$1 + shift + local arg + for arg ; do + (( $arg < result )) && result=$arg + done + (( result )) # return +} +functions -M min 1 -1 zsh_math_func_min # at least one argument -zsh_math_func_min zsh_math_func_max() { +zsh_math_func_max() { local result=$1 shift local arg for arg ; do - case $0 in - (*max) (( $arg > result )) && result=$arg;; - (*min) (( $arg < result )) && result=$arg;; - esac + (( $arg > result )) && result=$arg done (( result )) # return } functions -M max 1 -1 zsh_math_func_max # at least one argument -functions -M min 1 -1 zsh_math_func_min # at least one argument zsh_math_func_sum() { local sum ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-14 14:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAKc7PVDCOPzbU25+vTAXMQjonS1sznDX_SBq4-8rUZPQewa5Tg@mail.gmail.com> [not found] ` <CAKc7PVAe0N2bp2XS5U4mOKnTgxQRsj4UGy7NQpHput9VsbnAJw@mail.gmail.com> [not found] ` <160130085456.ZM9730__49922.0612728552$1454172936$gmane$org@torch.brasslantern.com> [not found] ` <20160207002212.GC24068@tarsus.local2> [not found] ` <160206170040.ZM1927__13399.3204137825$1454806909$gmane$org@torch.brasslantern.com> [not found] ` <20160209032308.GA20947@tarsus.local2> 2016-02-09 5:22 ` min() max() math functions (was: Re: Feature request (@M):# with context matches) Bart Schaefer 2016-02-10 9:23 ` Daniel Shahaf 2016-02-10 17:41 ` Bart Schaefer 2016-02-14 14:33 ` Daniel Shahaf
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).