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 17:33:35 +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 1083081587 18002 80.91.224.253 (27 Apr 2004 15:59:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2004 15:59:47 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 27 17:59:21 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 1BIUzR-00012v-00 for ; Tue, 27 Apr 2004 17:59:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIUzQ-0000kp-00 for ; Tue, 27 Apr 2004 17:59:20 +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 1BIUuV-0006h0-70 for emacs-devel@quimby.gnus.org; Tue, 27 Apr 2004 11:54:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIUrb-0006HY-IB for emacs-devel@gnu.org; Tue, 27 Apr 2004 11:51:15 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIUqx-00065S-44 for emacs-devel@gnu.org; Tue, 27 Apr 2004 11:51:06 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIUaX-0002Q9-G5 for emacs-devel@gnu.org; Tue, 27 Apr 2004 11:33:37 -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 1BIUYW-0000dN-4U; Tue, 27 Apr 2004 11:31:32 -0400 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 82 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:22247 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22247 Stefan Monnier writes: > > Give PROCESS the filter function FILTER; nil means no filter. > > What happens to output when there's no filter? It is inserted into the process buffer at point (default behavior). > > 1) a function which gets two arguments. [insert old description] > > Good. > > > 2) a buffer into which output gets inserted. > > Good. > > > 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. > > 4) t to stop accepting output. > > What happens to the output? Is it read&thrown away or not read? Neither. File descriptor is closed. That means that there is no output to accept: write calls of the generating process will fail with something like EPIPE. > > 5) a list of filter/file descriptor associations. The car's of > > the elements of this list are an item from 1)-4) as above, while > > the cdr is a list of file ids for which this item is supposed to > > apply. > > Sounds good. > > > This does not yet do everything needed for a full-bodied eshell: input > > redirections (including procedural input, equivalents to filter > > functions) and output appending redirection (>>) are not covered > > yet. But it would be a first step. > > Output-appending can be done via a filter-function. 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. > What kind of procedural input are you thinking of that can't be done > via process-send-string? process-send-string blocks when a pipe is full. Also it only works on file descriptor 0, ever. If I do something like a shell redirection: some command < What is still missing is the ability to open more file descriptors > than stdin, stdout, stderr. Item 5) above was supposed to cater for that. What really is missing is the ability to open a pipe that will, again, work without Emacs' intervention. Not sure how to do this. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum