comparison lispref/processes.texi @ 66152:6677034b52bb

(Sentinels): Clarify about output and quitting. (Filter Functions): Mention with-local-quit.

66151:934d10a9685c

and a string, which is output just received from it.  The function is
then free to do whatever it chooses with the output.

  Quitting is normally inhibited within a filter function---otherwise,
the effect of typing @kbd{C-g} at command level or to quit a user
command would be unpredictable.  If you want to permit quitting inside a
filter function, bind @code{inhibit-quit} to @code{nil}.
@xref{Quitting}.

  If an error happens during execution of a filter function, it is
caught automatically, so that it doesn't stop the execution of whatever
program was running when the filter function was started.  However, if
@code{debug-on-error} is non-@code{nil}, the error-catching is turned

there has been a change.  Therefore two changes in status, coming in
quick succession, can call the sentinel just once.  However, process
termination will always run the sentinel exactly once.  This is
because the process status can't change again after termination.

  Quitting is normally inhibited within a sentinel---otherwise, the
effect of typing @kbd{C-g} at command level or to quit a user command
would be unpredictable.  If you want to permit quitting inside a
sentinel, bind @code{inhibit-quit} to @code{nil}.  @xref{Quitting}.

  A sentinel that writes the output into the buffer of the process
should check whether the buffer is still alive.  If it tries to insert
into a dead buffer, it will get an error.  If the buffer is dead,
@code{(buffer-name (process-buffer @var{process}))} returns @code{nil}.

  If an error happens during execution of a sentinel, it is caught
automatically, so that it doesn't stop the execution of whatever
programs was running when the sentinel was started.  However, if
@code{debug-on-error} is non-@code{nil}, the error-catching is turned

66152:6677034b52bb

and a string, which is output just received from it.  The function is
then free to do whatever it chooses with the output.

  Quitting is normally inhibited within a filter function---otherwise,
the effect of typing @kbd{C-g} at command level or to quit a user
command would be unpredictable.  If you want to permit quitting inside
a filter function, bind @code{inhibit-quit} to @code{nil}.  In most
cases, the right way to do this is with the macro
@code{with-local-quit}.  @xref{Quitting}.

  If an error happens during execution of a filter function, it is
caught automatically, so that it doesn't stop the execution of whatever
program was running when the filter function was started.  However, if
@code{debug-on-error} is non-@code{nil}, the error-catching is turned

there has been a change.  Therefore two changes in status, coming in
quick succession, can call the sentinel just once.  However, process
termination will always run the sentinel exactly once.  This is
because the process status can't change again after termination.

  Emacs explicitly checks for output from the process before running
the process sentinel.  Once the sentinel runs due to process
termination, no further output can arrive from the process.

  A sentinel that writes the output into the buffer of the process
should check whether the buffer is still alive.  If it tries to insert
into a dead buffer, it will get an error.  If the buffer is dead,
@code{(buffer-name (process-buffer @var{process}))} returns @code{nil}.

  Quitting is normally inhibited within a sentinel---otherwise, the
effect of typing @kbd{C-g} at command level or to quit a user command
would be unpredictable.  If you want to permit quitting inside a
sentinel, bind @code{inhibit-quit} to @code{nil}.  In most cases, the
right way to do this is with the macro @code{with-local-quit}.
@xref{Quitting}.

  If an error happens during execution of a sentinel, it is caught
automatically, so that it doesn't stop the execution of whatever
programs was running when the sentinel was started.  However, if
@code{debug-on-error} is non-@code{nil}, the error-catching is turned