bug#10598: 24.0.92; run dired-do-async-shell-command on multiple files individually

[Roland Winkler]

On Sat Jul 14 2012 Juri Linkov wrote:
> A good UI to select the desired behavior before the command invocation
> is to use a prefix argument.  A comment in `dired-shell-stuff-it'
> says:

...much agreed -- if these had not already established their own
usage of the prefix arg. The command dired-do-async-shell-command
uses the prefix arg like dired-do-shell-command, that is, the prefix
arg is one method (besides the mark) to determine the file list the
shell commands will work on. Changing this established behavior for
dired-do-async-shell-command (while possibly keeping the current
behavior for dired-do-shell-command) is probably confusing.

>   ;; Might be redefined for smarter things and could then use RAW-ARG
>   ;; (coming from interactive P and currently ignored) to decide what to do.
>   ;; Smart would be a way to access basename or extension of file names.
> 
> I don't know how it was intended to be implemented a smart way, but
> maybe the same could be used to specify how to run dired async commands?

I guess that this can only refer to the handling of file arguments,
but the prefix cannot be used (anymore) for a completely different
purpose.

Currently the COMMAND arg knows three special characters, *. ?, and
&. How about a fourth character ";"? More specifically:

 & means: run asynchronously, separating with &
 ; means: run asynchronously, separating with ;

I believe this should not break too much backward compatibility
because ; normally needs to be protected anyway.

Then & becomes the default of dired-do-async-shell-command. Anyway,
& is appended only if it is not yet present.

Or am I missing something? Would this break something?