On Sun, Dec 16, 2018 at 11:54:08AM +0000, Daniel Shahaf wrote: > Let me begin by saying I'm not familiar enough with the parser to have > an opinion on whether it would be better to have change the docs to > match the code, or change the code to match the docs, or leave this as > an implementation detail that's subject to change. Agreed, that's probably a good idea. > All that said, I'm not too bothered by the grammar of the log message > (which is now explained in this thread anyway). I'd sooner suggest > changes to the new text: > > > +++ b/Doc/Zsh/grammar.yo > > @@ -185,11 +185,12 @@ cindex(loops, for) > > item(tt(for) var(name) ... [ tt(in) var(word) ... ] var(term) tt(do) var(list) tt(done))( > > where var(term) is at least one newline or tt(;). > > Expand the list of var(word)s, and set the parameter > > var(name) to each of them in turn, executing > > var(list) each time. If the tt(in) var(word) is omitted, > > -use the positional parameters instead of the var(word)s. > > +use the positional parameters with a var(term) implicitly > > +appended instead of the var(word)s. > > > > Two issues here: > > 1. The docs of var(term) are spread across the first and last sentence. Yes, that is a bit awkward. I should find a better way to organize that. > 2. Adding a side remark about var(term) to the last sentence may obscure > that sentence's primary point about the fallback to positional > parameters. > > So, perhaps something like this (relative to master): > > -where var(term) is at least one newline or tt(;). > Expand the list of var(word)s, and set the parameter > var(name) to each of them in turn, executing > -var(list) each time. If the tt(in) var(word) is omitted, > +var(list) each time. If the `tt(in) var(word)' is omitted, > use the positional parameters instead of the var(word)s. > + > +var(term) should be one or more newline or tt(;), and is optional if > +the `tt(in) var(word)' is omitted. Aha, optional works great here. > But let's wait for someone familiar with the parser to opine on the > proposed strategic direction ("document the parser's behaviour") before > we spend too much time on implementing that. But again agreed, I'll wait for someone who knows the parser well (Bart maybe?) to chime in before I cook up a v2. -- Cheers, Joey Pabalinas