Make call-process (and start-process?) filename handlers?

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

I think it would be good to change call-process to check for a
filename handler, based on the value of default-directory.

VC uses call-process (or start-process) for the external programs;
with this change it would automagically work for remote files.  (If
the corresponding filename handler implements call-process, of
course.)

Currently, shell-command chooses a filename handler based on
default-directory.  call-process is not currently a file operation.

Previously, Richard suggested to implement an operation
process-file.  One of the arguments would be the filename to use for
finding the right filename handler.

I think that process-file leads to unnecessary complications.  For
example, what happens if the file to process is /user@host:/file1 and
one of the other args is /user@host:/file2?  Should that be
interpreted as a filename and passed to the remote program as "/file2"
or "file2"?  Or should it be interpreted as a string and passed as
"/user@host:/file2"?  Clearly, it can be both, so the interface for
process-file needs to provide a way to specify which interpretation
to use.  Another complication is that the filename that determines
the handler can be at various positions in the arg list, which makes
the interface to process-file complicated.

With call-process, one can just make all filenames relative to
default-directory before invoking call-process.  Then it will just
work.

In the unlikely event that somebody successfully invoked call-process
where default-directory was pointing to a remote directory, this
invocation can easily be rectified by let-binding default-directory
to "/" (on Windows, maybe "c:/"?) arount that problematic
invocation.  I have not done investigations on how unlikely that
event is, though.

What do people think?
-- 
Ambibibentists unite!