From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Proposal for extending set-process-filter Date: 27 Apr 2004 22:46:07 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083098929 5759 80.91.224.253 (27 Apr 2004 20:48:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2004 20:48:49 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 27 22:48:40 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIZVP-0000Jy-00 for ; Tue, 27 Apr 2004 22:48:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIZVP-0005Vw-00 for ; Tue, 27 Apr 2004 22:48:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIZV8-0002J4-Cf for emacs-devel@quimby.gnus.org; Tue, 27 Apr 2004 16:48:22 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIZV1-0002H3-Oi for emacs-devel@gnu.org; Tue, 27 Apr 2004 16:48:15 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIZUT-00023A-Ee for emacs-devel@gnu.org; Tue, 27 Apr 2004 16:48:12 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIZSz-0001S7-T6 for emacs-devel@gnu.org; Tue, 27 Apr 2004 16:46:09 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BIZQv-0007RK-EK; Tue, 27 Apr 2004 16:44:01 -0400 Original-To: Stefan Monnier In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22265 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22265 Stefan Monnier writes: > >> > 3) a file name for output. > >> Can be handled by (1) just fine. What would you use it for (other than > >> /dev/null which is rather special since append is the same as overwrite)? > > Consistency with the BUFFER argument of start-process (which would be > > pretty much the same as the FILTER function, with the exception that > > it establishes a control buffer that is the default for process > > output, that will list the process as one of its processes, and that > > will kill the process if the buffer gets killed). Also efficiency: > > redirecting a file descriptor to a file does not require Emacs > > processing power. It also does not require conversion into multibyte > > strings and back and so on. > > AFAIK, you can't do such a redirection after the exec. I.e. it has > to be an argument of `start-process' rather than set-process-filter. Ouch. I am so stupid. In that case, the whole folderol obviously needs to be made some option right at start-process time. I'll have to think more about this. > > Not really. An open in append mode will also append at the end if > > the file gets extended by a different process. That's pretty hard to > > do with a filter function. One could start the file descriptor list > > with > > :append t > > or so, however. > > I thought the `append' arg of write-region did it right. Probably. But it would be quite wasteful to use Emacs for that. But since I forgot in my stupidity that once the fork has happened, we can't work on anything but the pipe, of course one can't avoid Emacs reading on the pipe. Again, the _intent_ of the proposal was to allow redirections and stuff like in a shell, and also different filter functions on different file descriptors. Naturally, it fails. The stuff needs to be specified before exec. > But for the same reason as above I don't think this can be done in > set-process-filter: it has to be done before the `exec'. Yes. I am glad that there is somebody with a brain on one end of our connection. So obviously, this would need to be changed into a proposal for start-process. The BUFFER argument might be replaced by a cons cell where the CAR is the previous BUFFER argument (meaning the buffer that the process will get associated with), and the CDR is the contraption that I proposed for set-process-filter. set-process-filter could still work as described, but it obviously would only be allowed to apply to file descriptors under Emacs control (namely, pointing to a buffer or filter function), and not file descriptors closed or redirected to a file. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum