> > I noticed that the "barking" is conditional to "success". ISTM that it > should always "bark" in interactive mode, whether success or not. >
"success" in those cases means "the expression was a valid boolean", and non-success cases (should) result in an error being printed regardless of interactive mode. If you see otherwise, let me know. > > While testing it and seeing the code, I agree that it is too > verbose/redundant. At least remove "active/inactive, ". Have done so, new patch pending "how-do-I-know-when-input-is-empty" in Ctrl C. > - Help text. New block in help text called "Conditionals" >> > > Maybe it could be moved to "Input/Output" renamed as "Input/Output > Control", or maybe the "Conditionals" section could be moved next to it, it > seems more logical than after large objects. > I put it near the bottom, figuring someone would have a better idea of where to put it. You did. > I think that the descriptions are too long. The interactive user can be > trusted to know what "if/elif/else/endif" mean, or to refer to the full > documentation otherwise. The point is just to provide a syntax and function > reminder, not a substitute for the doc. Thus I would suggest shorter > one-line messages like: > > \if <expr> begin a new conditional block > \elif <expr> else if in the current conditional block > \else else in current conditional block > \endif end current conditional block > +1 > >> > Hmmm. Perl is perl. Attached an attempt at improving that, which is > probably debatable, but at least it is easy to add further tests without > massive copy-pasting. +1 that's a good start. > > > - regression tests now have comments to explain purpose >> > > Ok. > > Small details about the code: > > + if (!pset.active_branch && !is_branching_command(cmd) ) > > Not sure why there is a space before the last closing parenthesis. +1
