From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.devel Subject: Make call-process (and start-process?) filename handlers? Date: Sat, 28 Dec 2002 23:31:54 +0100 Organization: University of Dortmund, Germany Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <84isxdpyg5.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041114837 15234 80.91.224.249 (28 Dec 2002 22:33:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 28 Dec 2002 22:33:57 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18SPWm-0003xa-00 for ; Sat, 28 Dec 2002 23:33:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18SPXZ-0007Cl-00 for ; Sat, 28 Dec 2002 23:34:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18SPWT-0003UN-0B for emacs-devel@quimby.gnus.org; Sat, 28 Dec 2002 17:33:37 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18SPVz-0002oQ-00 for emacs-devel@gnu.org; Sat, 28 Dec 2002 17:33:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18SPVs-0002dP-00 for emacs-devel@gnu.org; Sat, 28 Dec 2002 17:33:01 -0500 Original-Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18SPVk-0002Q4-00 for emacs-devel@gnu.org; Sat, 28 Dec 2002 17:32:52 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18SPUT-0003r2-00 for ; Sat, 28 Dec 2002 23:31:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18SPUM-0003qa-00 for ; Sat, 28 Dec 2002 23:31:26 +0100 Original-Path: not-for-mail Original-Lines: 40 Original-X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Cancel-Lock: sha1:brdwYUV9pXFf1sRhrEyOaWfrRmQ= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10362 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10362 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!