Add --pipe for receiving a machine readable format of a command.

It wasn't clear to me how this could be used by the autocomplete script. I guess we could make --backend into an option rather than just a flag, so you could specify --backend=json or --backend=delimited or if we could do some kind of combo - so that if you specify --quiet as well as --backend you get space delimited output. Alternatively it could be more convenient to have some kind of unlisted meta-command that can call the commands (with a little logic as needed) collates and returns the string itself.

I am not sure what the most convenient format for the autocomplete script would be - I am guessing space delimited strings but who knows - a delimiter option might be handy. The other thing worth thinking about is caching - even with the results being quick to come back it testing the timing of throw them in some temporary/hidden file (probably per site?) and refreshing every hour or whatever.

I don't like merging this in with the logging functionality, i think it's closer to drush_print than drush_log.

drush_error_log exists, because we need to be able to run drush_cmp_error to check whether a certain error occurs.

In the initial iteration of drush_backend_iterate, it would merge the errors first and then the rest of the messages excluding the errors (kind of what you're doing here).

I still include the error_log array, for processes that do not want to integrate the output (say for instance a script that needs to run on multiple sites without stopping if one of them returns an error). This way they can do an if array_key_exists on the error_log returned from the script.

What you are looking for here is a specific switch to change output into a machine readable format, which is closer to what drush_print does.

is the new "--pipe" option relevant in this discussion? It sounds exactly like the thing we seek to develop here - sth like --backend's younger brother for humans? Ideally --pipe would just pretty print --backend's data.

as for the way autocomplete could use this : my autocomplete draft script will happily eat up and parse whatever form of somehow structured lists of commands, options and optionally enabled/disabled modules you give it...

For example I am quite happy with the present "drush help --backend" JSON output. It is fast which is most important

offtopic: "Lets get autocomplete for just command name and then see if we want to extend it. " - agree 100% - commands is enough for now and maybe even for-ever