From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.devel Subject: Re: Patch: new function process-file (call-process with file handlers) Date: Mon, 18 Oct 2004 08:44:53 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <866558msnu.fsf@ketchup.de.uu.net> References: <863c0dnxxe.fsf@ketchup.de.uu.net> <86y8i5m9tf.fsf@ketchup.de.uu.net> <877jppm5x6.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098081936 2445 80.91.229.6 (18 Oct 2004 06:45:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Oct 2004 06:45:36 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 18 08:45:29 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CJRGr-0007jW-00 for ; Mon, 18 Oct 2004 08:45:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJRO8-0000rd-Gs for ged-emacs-devel@m.gmane.org; Mon, 18 Oct 2004 02:53:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CJRO2-0000rR-L1 for emacs-devel@gnu.org; Mon, 18 Oct 2004 02:52:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CJRO1-0000r2-SR for emacs-devel@gnu.org; Mon, 18 Oct 2004 02:52:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CJRO1-0000qz-PI for emacs-devel@gnu.org; Mon, 18 Oct 2004 02:52:53 -0400 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CJRGP-000214-0f for emacs-devel@gnu.org; Mon, 18 Oct 2004 02:45:01 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CJRGO-0003v5-00 for ; Mon, 18 Oct 2004 08:45:00 +0200 Original-Received: from ketchup.de.uu.net ([139.4.38.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Oct 2004 08:45:00 +0200 Original-Received: from kai by ketchup.de.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Oct 2004 08:45:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 49 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ketchup.de.uu.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:EynS4Wo080toIv9lD3uWvw4TL4g= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28547 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28547 Stefan Monnier writes: >> +(defun process-file (program &optional infile buffer display &rest args) >> + "Process files synchronously in a separate process. >> +Similar to `call-process', but may invoke a file handler based on >> +`default-directory'. The current working directory of the >> +subprocess is `default-directory'. >> + >> +File names in INFILE and BUFFER are handled normally, but file >> +names in ARGS should be relative to `default-directory', as they >> +are passed to the process verbatim. >> + >> +Some file handlers might not support all variants, for example >> +they might behave as if DISPLAY was nil, regardless of the actual >> +value passed." >> + (let ((fh (find-file-name-handler default-directory 'process-file))) >> + (if fh (apply fh 'process-file program infile buffer display args) >> + (apply 'call-process program infile buffer display args)))) > > Looks good to me, except I'm not sure what INFILE should do. > > I guess we could use the following convention: if it is a relative file > name, then it's a file on the remote host, otherwise, it's a file on the > local host that should be passed "manually" by reading the file in a buffer > and feeding it via the stdin pipe. Well, INFILE should be fed to the stdin of the process, as for call-process. Why do we have to adopt a special convention, why can't INFILE be relative to default-directory, as normal? Hm. Now I see: call-process doesn't grok file handlers for the INFILE argument. So that means that process-file should invoke file-local-copy on the INFILE arg first. But if a file handler is invoked, it could handle INFILE itself. It would be an optimization whether or not the contents are passed via a buffer or directly via a file. > Same thing for STDERR-FILE. Right. I guess process-file would need to wrap that one, too, for the no-handler case. I'm unsure whether this is the right time to install a change like this. OT1H, it's a new feature, OTOH, it helps to avoid defadvice and that is desirable. Kai