Port `start-file-process' and `start-file-process-shell-command'

Michael Sperber writes:

 > +;;;###autoload
 > +(defun start-file-process (name buffer program &rest program-args)
 > +  "Start a program in a subprocess.  Return the process object for it.
 > +
 > +Similar to `start-process', but may invoke a file handler based on
 > +`default-directory'.  See Info node `(elisp)Magic File Names'.
 > +
 > +This handler ought to run PROGRAM, perhaps on the local host,
 > +perhaps on a remote host that corresponds to `default-directory'.

What is the format of remote host specification?

 > +In the latter case, the local part of `default-directory' becomes
 > +the working directory of the process.
 > +
 > +PROGRAM and PROGRAM-ARGS might be file names.

Erm, what else might they be?

 > +They are not
 > +objects of file handler invocation.  File handlers might not
 > +support pty association, if PROGRAM is nil."

Do we need that last sentence?  If it's rationale for *why* we don't
invoke file handlers, it doesn't belong in the docstring.  Maybe in a
comment.  If it is needed, I have no clue what it means.

 > +  (let ((fh (find-file-name-handler default-directory 'start-file-process)))
 > +    (if fh (apply fh 'start-file-process name buffer program program-args)
 > +      (apply 'start-process name buffer program program-args))))
 > +
 > +
 >  ;;; simple-more.el ends here
 > diff --git a/subr-more.el b/subr-more.el
 > --- a/subr-more.el
 > +++ b/subr-more.el
 > @@ -195,4 +195,14 @@
 >  	    tail (cdr tail)))
 >      result))
 >  
 > +;;;###autoload
 > +(defun start-file-process-shell-command (name buffer &rest args)
 > +  "Start a program in a subprocess.  Return the process object for it.
 > +Similar to `start-process-shell-command', but calls `start-file-process'."
 > +  (start-file-process
 > +   name buffer
 > +   (if (file-remote-p default-directory) "/bin/sh" shell-file-name)
 > +   (if (file-remote-p default-directory) "-c" shell-command-switch)
 > +   (mapconcat 'identity args " ")))
 > +
 >  ;;; subr-more.el ends here
 > 
 > _______________________________________________
 > XEmacs-Patches mailing list
 > [email protected]
 > http://lists.xemacs.org/mailman/listinfo/xemacs-patches