stderr from _call_program (Re: rsync --progress stops completion)

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

On 20 Sep, Bart wrote:
> }
> } _call_program could throw away
> } stderr unless something like -e is passed. But should -e imply 2>&1?
> 
> No, this can't work.  _call_program runs an "eval" on the value of the
> "command" zstyle in preference to its argument list, so it has no way
> of knowing whether it's appropriate to insert "2>&1".

I think we can safely append 2>/dev/null to the eval. If the command
(either from a zstyle preference or the function) uses 2>&1, output
should be captured:
  % eval 'unknown 2>&1' 2>/dev/null 
  zsh: command not found: unknown

> If nearly half of all functions are getting this wrong, and 90%+ of
> all functions need a certain behavior, that behavior probably should
> be the default, don't you think?

Yes. Provided it is still possible to implement the remaining 10%.
 
> An explicit 2>/dev/null where?  In the completion function use of
> _call_program?  Except that anyone looking at function source as an

Yes, in the completion function.

> (One could argue that the whole completion system should be capturing
> stderr somewhere and showing it to the user in a controlled way rather
> than letting it scramble the display, but that's a larger issue.)
 
Another possibility along similar lines would be to install a
command_not_found_handler function for the duration of the completion
system. Avoiding command not found errors is the main (but not only)
reason for redirecting stderr with _call_program.

We should also consider _complete_debug, perhaps directing stderr to the
log file instead of /dev/null.

Oliver