[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to emacs/lispref/processes.texi
From: |
Luc Teirlinck |
Subject: |
[Emacs-diffs] Changes to emacs/lispref/processes.texi |
Date: |
Fri, 17 Jun 2005 11:05:24 -0400 |
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 */];
@};
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Richard M . Stallman, 2005/06/17
- [Emacs-diffs] Changes to emacs/lispref/processes.texi,
Luc Teirlinck <=
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Luc Teirlinck, 2005/06/17
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Luc Teirlinck, 2005/06/17
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Luc Teirlinck, 2005/06/17
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Luc Teirlinck, 2005/06/17
- [Emacs-diffs] Changes to emacs/lispref/processes.texi, Richard M . Stallman, 2005/06/18