Re: Proposal for extending set-process-filter

[David Kastrup]

Stefan Monnier <address@hidden> 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 <<EOF &
lots of text
EOF

then eshell would block if "lots of text" would be more than a pipe's
worth.

> 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