[Emacs-diffs] Changes to emacs/lispref/processes.texi

[Luc Teirlinck]

Index: emacs/lispref/processes.texi
diff -c emacs/lispref/processes.texi:1.59 emacs/lispref/processes.texi:1.60
*** emacs/lispref/processes.texi:1.59   Fri Jun 17 13:51:19 2005
--- emacs/lispref/processes.texi        Fri Jun 17 15:05:23 2005
***************
*** 767,775 ****
  data appears on the ``standard input'' of the subprocess.
  
    Some operating systems have limited space for buffered input in a
! @acronym{PTY}.  On these systems, Emacs sends an @acronym{EOF} periodically 
amidst
! the other characters, to force them through.  For most programs,
! these @acronym{EOF}s do no harm.
  
    Subprocess input is normally encoded using a coding system before the
  subprocess receives it, much like text written into a file.  You can use
--- 767,775 ----
  data appears on the ``standard input'' of the subprocess.
  
    Some operating systems have limited space for buffered input in a
! @acronym{PTY}.  On these systems, Emacs sends an @acronym{EOF}
! periodically amidst the other characters, to force them through.  For
! most programs, these @acronym{EOF}s do no harm.
  
    Subprocess input is normally encoded using a coding system before the
  subprocess receives it, much like text written into a file.  You can use
***************
*** 973,979 ****
  @defvar process-adaptive-read-buffering
  On some systems, when Emacs reads the output from a subprocess, the
  output data is read in very small blocks, potentially resulting in
! very poor performance.  This behaviour can be remedied to some extent
  by setting the variable @var{process-adaptive-read-buffering} to a
  address@hidden value (the default), as it will automatically delay reading
  from such processes, thus allowing them to produce more output before
--- 973,979 ----
  @defvar process-adaptive-read-buffering
  On some systems, when Emacs reads the output from a subprocess, the
  output data is read in very small blocks, potentially resulting in
! very poor performance.  This behavior can be remedied to some extent
  by setting the variable @var{process-adaptive-read-buffering} to a
  address@hidden value (the default), as it will automatically delay reading
  from such processes, thus allowing them to produce more output before
***************
*** 1560,1566 ****
  keyword/argument pairs, for example @code{:server t} to create a
  server process, or @code{:type 'datagram} to create a datagram
  connection.  @xref{Low-Level Network}, for details.  You can also use
! the @code{open-network-stream} function descibed below.
  
    You can distinguish process objects representing network connections
  and servers from those representing subprocesses with the
--- 1560,1566 ----
  keyword/argument pairs, for example @code{:server t} to create a
  server process, or @code{:type 'datagram} to create a datagram
  connection.  @xref{Low-Level Network}, for details.  You can also use
! the @code{open-network-stream} function described below.
  
    You can distinguish process objects representing network connections
  and servers from those representing subprocesses with the
***************
*** 1824,1830 ****
  is to determine the coding systems from the data.
  
  @item :noquery @var{query-flag}
! Initialize the process query flag to @var{query-flag}.  @xref{Query Before 
Exit}.
  
  @item :filter @var{filter}
  Initialize the process filter to @var{filter}.
--- 1824,1831 ----
  is to determine the coding systems from the data.
  
  @item :noquery @var{query-flag}
! Initialize the process query flag to @var{query-flag}.
! @xref{Query Before Exit}.
  
  @item :filter @var{filter}
  Initialize the process filter to @var{filter}.
***************
*** 1939,1945 ****
  
  @defun network-interface-info ifname
  This function returns information about the network interface named
! @var{ifname}.  The value is a list of the form @code{(@var{addr} @var{bcast} 
@var{netmask} @var{hwaddr} @var{flags})}.
  
  @table @var
  @item addr
--- 1940,1947 ----
  
  @defun network-interface-info ifname
  This function returns information about the network interface named
! @var{ifname}.  The value is a list of the form
! @code{(@var{addr} @var{bcast} @var{netmask} @var{hwaddr} @var{flags})}.
  
  @table @var
  @item addr
***************
*** 2020,2026 ****
  @section Packing and Unpacking Byte Arrays
  
    This section describes how to pack and unpack arrays of bytes,
! usually for binary network protocols.  These functoins byte arrays to
  alists, and vice versa.  The byte array can be represented as a
  unibyte string or as a vector of integers, while the alist associates
  symbols either with fixed-size objects or with recursive sub-alists.
--- 2022,2028 ----
  @section Packing and Unpacking Byte Arrays
  
    This section describes how to pack and unpack arrays of bytes,
! usually for binary network protocols.  These functions byte arrays to
  alists, and vice versa.  The byte array can be represented as a
  unibyte string or as a vector of integers, while the alist associates
  symbols either with fixed-size objects or with recursive sub-alists.
***************
*** 2053,2059 ****
  @cindex network byte ordering
    A field's @dfn{type} describes the size (in bytes) of the object
  that the field represents and, in the case of multibyte fields, how
! the bytes are ordered within the firld.  The two possible orderings
  are ``big endian'' (also known as ``network byte ordering'') and
  ``little endian''.  For instance, the number @code{#x23cd} (decimal
  9165) in big endian would be the two bytes @code{#x23} @code{#xcd};
--- 2055,2061 ----
  @cindex network byte ordering
    A field's @dfn{type} describes the size (in bytes) of the object
  that the field represents and, in the case of multibyte fields, how
! the bytes are ordered within the field.  The two possible orderings
  are ``big endian'' (also known as ``network byte ordering'') and
  ``little endian''.  For instance, the number @code{#x23cd} (decimal
  9165) in big endian would be the two bytes @code{#x23} @code{#xcd};
***************
*** 2100,2106 ****
  @item bits @var{len}
  List of set bits in @var{len} bytes.  The bytes are taken in big
  endian order and the bits are numbered starting with @code{8 *
! @var{len} @minus{} 1}} and ending with zero.  For example: @code{bits
  2} unpacks @code{#x28} @code{#x1c} to @code{(2 3 4 11 13)} and
  @code{#x1c} @code{#x28} to @code{(3 5 10 11 12)}.
  
--- 2102,2108 ----
  @item bits @var{len}
  List of set bits in @var{len} bytes.  The bytes are taken in big
  endian order and the bits are numbered starting with @code{8 *
! @var{len} @minus{} 1} and ending with zero.  For example: @code{bits
  2} unpacks @code{#x28} @code{#x1c} to @code{(2 3 4 11 13)} and
  @code{#x1c} @code{#x28} to @code{(3 5 10 11 12)}.
  
***************
*** 2153,2159 ****
  Skip to the next multiple of @var{len} bytes.
  
  @item struct @var{spec-name}
! Process @var{spec-name} as a sub-specification.  This descrobes a
  structure nested within another structure.
  
  @item union @var{form} (@var{tag} @var{spec})@dots{}
--- 2155,2161 ----
  Skip to the next multiple of @var{len} bytes.
  
  @item struct @var{spec-name}
! Process @var{spec-name} as a sub-specification.  This describes a
  structure nested within another structure.
  
  @item union @var{form} (@var{tag} @var{spec})@dots{}
***************
*** 2223,2233 ****
  This function returns a byte array packed according to @var{spec} from
  the data in the alist @var{struct}.  Normally it creates and fills a
  new byte array starting at the beginning.  However, if @var{raw-data}
! is address@hidden, it speciries a pre-allocated string or vector to
  pack into.  If @var{pos} is address@hidden, it specifies the starting
  offset for packing into @code{raw-data}.
  
! @c ??? Isn't this a bug?  Shoudn't it always be unibyte?
  Note: The result is a multibyte string; use @code{string-make-unibyte}
  on it to make it unibyte if necessary.
  @end defun
--- 2225,2235 ----
  This function returns a byte array packed according to @var{spec} from
  the data in the alist @var{struct}.  Normally it creates and fills a
  new byte array starting at the beginning.  However, if @var{raw-data}
! is address@hidden, it specifies a pre-allocated string or vector to
  pack into.  If @var{pos} is address@hidden, it specifies the starting
  offset for packing into @code{raw-data}.
  
! @c ??? Isn't this a bug?  Shouldn't it always be unibyte?
  Note: The result is a multibyte string; use @code{string-make-unibyte}
  on it to make it unibyte if necessary.
  @end defun
***************
*** 2340,2346 ****
      unsigned char    type;
      unsigned char    opcode;
      unsigned long    length;  /* In little endian order */
!     unsigned char    id[8];   /* nul-terminated string  */
      unsigned char    data[/* (length + 3) & ~3 */];
  @};
  
--- 2342,2348 ----
      unsigned char    type;
      unsigned char    opcode;
      unsigned long    length;  /* In little endian order */
!     unsigned char    id[8];   /* null-terminated string  */
      unsigned char    data[/* (length + 3) & ~3 */];
  @};