Created branch scriptics-tclpro-1-2-syntheticscriptics_tclpro_1_2scriptics_tclpro_1_2_synthetic

4 files changed, 0 insertions, 1326 deletions

diff --git a/doc/DString.3 b/doc/DString.3
deleted file mode 100644
index e8cc5e1..0000000
--- a/doc/DString.3
+++ /dev/null
@@ -1,145 +0,0 @@
-'\"
-'\" Copyright (c) 1993 The Regents of the University of California.
-'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
-'\"
-'\" See the file "license.terms" for information on usage and redistribution
-'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\" 
-'\" RCS: @(#) $Id: DString.3,v 1.2 1998/09/14 18:39:48 stanton Exp $
-'\" 
-.so man.macros
-.TH Tcl_DString 3 7.4 Tcl "Tcl Library Procedures"
-.BS
-.SH NAME
-Tcl_DStringInit, Tcl_DStringAppend, Tcl_DStringAppendElement, Tcl_DStringStartSublist, Tcl_DStringEndSublist, Tcl_DStringLength, Tcl_DStringValue, Tcl_DStringSetLength, Tcl_DStringFree, Tcl_DStringResult, Tcl_DStringGetResult \- manipulate dynamic strings
-.SH SYNOPSIS
-.nf
-\fB#include <tcl.h>\fR
-.sp
-\fBTcl_DStringInit\fR(\fIdsPtr\fR)
-.sp
-char *
-\fBTcl_DStringAppend\fR(\fIdsPtr, string, length\fR)
-.sp
-char *
-\fBTcl_DStringAppendElement\fR(\fIdsPtr, string\fR)
-.sp
-\fBTcl_DStringStartSublist\fR(\fIdsPtr\fR)
-.sp
-\fBTcl_DStringEndSublist\fR(\fIdsPtr\fR)
-.sp
-int
-\fBTcl_DStringLength\fR(\fIdsPtr\fR)
-.sp
-char *
-\fBTcl_DStringValue\fR(\fIdsPtr\fR)
-.sp
-\fBTcl_DStringSetLength\fR(\fIdsPtr, newLength\fR)
-.sp
-\fBTcl_DStringFree\fR(\fIdsPtr\fR)
-.sp
-\fBTcl_DStringResult\fR(\fIinterp, dsPtr\fR)
-.sp
-\fBTcl_DStringGetResult\fR(\fIinterp, dsPtr\fR)
-.SH ARGUMENTS
-.AS Tcl_DString newLength
-.AP Tcl_DString *dsPtr in/out
-Pointer to structure that is used to manage a dynamic string.
-.AP char *string in
-Pointer to characters to add to dynamic string.
-.AP int length in
-Number of characters from string to add to dynamic string.  If -1,
-add all characters up to null terminating character.
-.AP int newLength in
-New length for dynamic string, not including null terminating
-character.
-.AP Tcl_Interp *interp in/out
-Interpreter whose result is to be set from or moved to the
-dynamic string.
-.BE
-
-.SH DESCRIPTION
-.PP
-Dynamic strings provide a mechanism for building up arbitrarily long
-strings by gradually appending information.  If the dynamic string is
-short then there will be no memory allocation overhead;  as the string
-gets larger, additional space will be allocated as needed.
-.PP
-\fBTcl_DStringInit\fR initializes a dynamic string to zero length.
-The Tcl_DString structure must have been allocated by the caller.
-No assumptions are made about the current state of the structure;
-anything already in it is discarded.
-If the structure has been used previously, \fBTcl_DStringFree\fR should
-be called first to free up any memory allocated for the old
-string.
-.PP
-\fBTcl_DStringAppend\fR adds new information to a dynamic string,
-allocating more memory for the string if needed.
-If \fIlength\fR is less than zero then everything in \fIstring\fR
-is appended to the dynamic string;  otherwise \fIlength\fR
-specifies the number of bytes to append.
-\fBTcl_DStringAppend\fR returns a pointer to the characters of
-the new string.  The string can also be retrieved from the
-\fIstring\fR field of the Tcl_DString structure.
-.PP
-\fBTcl_DStringAppendElement\fR is similar to \fBTcl_DStringAppend\fR
-except that it doesn't take a \fIlength\fR argument (it appends
-all of \fIstring\fR) and it converts the string to a proper list element
-before appending.
-\fBTcl_DStringAppendElement\fR adds a separator space before the
-new list element unless the new list element is the first in a
-list or sub-list (i.e. either the current string is empty, or it
-contains the single character ``{'', or the last two characters of
-the current string are `` {'').
-\fBTcl_DStringAppendElement\fR returns a pointer to the
-characters of the new string.
-.PP
-\fBTcl_DStringStartSublist\fR and \fBTcl_DStringEndSublist\fR can be
-used to create nested lists.
-To append a list element that is itself a sublist, first
-call \fBTcl_DStringStartSublist\fR, then call \fBTcl_DStringAppendElement\fR
-for each of the elements in the sublist, then call
-\fBTcl_DStringEndSublist\fR to end the sublist.
-\fBTcl_DStringStartSublist\fR appends a space character if needed,
-followed by an open brace;  \fBTcl_DStringEndSublist\fR appends
-a close brace.
-Lists can be nested to any depth.
-.PP
-\fBTcl_DStringLength\fR is a macro that returns the current length
-of a dynamic string (not including the terminating null character).
-\fBTcl_DStringValue\fR is a  macro that returns a pointer to the
-current contents of a dynamic string.
-.PP
-.PP
-\fBTcl_DStringSetLength\fR changes the length of a dynamic string.
-If \fInewLength\fR is less than the string's current length, then
-the string is truncated.
-If \fInewLength\fR is greater than the string's current length,
-then the string will become longer and new space will be allocated
-for the string if needed.
-However, \fBTcl_DStringSetLength\fR will not initialize the new
-space except to provide a terminating null character;  it is up to the
-caller to fill in the new space.
-\fBTcl_DStringSetLength\fR does not free up the string's storage space
-even if the string is truncated to zero length, so \fBTcl_DStringFree\fR
-will still need to be called.
-.PP
-\fBTcl_DStringFree\fR should be called when you're finished using
-the string.  It frees up any memory that was allocated for the string
-and reinitializes the string's value to an empty string.
-.PP
-\fBTcl_DStringResult\fR sets the result of \fIinterp\fR to the value of
-the dynamic string given by \fIdsPtr\fR.  It does this by moving
-a pointer from \fIdsPtr\fR to \fIinterp->result\fR.
-This saves the cost of allocating new memory and copying the string.
-\fBTcl_DStringResult\fR also reinitializes the dynamic string to
-an empty string.
-.PP
-\fBTcl_DStringGetResult\fR does the opposite of \fBTcl_DStringResult\fR.
-It sets the value of \fIdsPtr\fR to the result of \fIinterp\fR and
-it clears \fIinterp\fR's result.
-If possible it does this by moving a pointer rather than by copying
-the string.
-
-.SH KEYWORDS
-append, dynamic string, free, result
diff --git a/doc/Notifier.3 b/doc/Notifier.3
deleted file mode 100644
index dcd8250..0000000
--- a/doc/Notifier.3
+++ /dev/null
@@ -1,537 +0,0 @@
-'\"
-'\" Copyright (c) 1995-1997 Sun Microsystems, Inc.
-'\"
-'\" See the file "license.terms" for information on usage and redistribution
-'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\" 
-'\" RCS: @(#) $Id: Notifier.3,v 1.2 1998/09/14 18:39:49 stanton Exp $
-'\" 
-.so man.macros
-.TH Notifier 3 8.0 Tcl "Tcl Library Procedures"
-.BS
-.VS
-.SH NAME
-Tcl_CreateEventSource, Tcl_DeleteEventSource, Tcl_SetMaxBlockTime, Tcl_QueueEvent, Tcl_DeleteEvents, Tcl_WaitForEvent, Tcl_SetTimer, Tcl_ServiceAll, Tcl_ServiceEvent, Tcl_GetServiceMode, Tcl_SetServiceMode \- the event queue and notifier interfaces
-
-.SH SYNOPSIS
-.nf
-\fB#include <tcl.h>\fR
-.sp
-\fBTcl_CreateEventSource\fR(\fIsetupProc, checkProc, clientData\fB)\fR
-.sp
-\fBTcl_DeleteEventSource\fR(\fIsetupProc, checkProc, clientData\fB)\fR
-.sp
-\fBTcl_SetMaxBlockTime\fR(\fItimePtr\fB)\fR
-.sp
-\fBTcl_QueueEvent\fR(\fIevPtr, position\fR)
-.VS
-.sp
-\fBTcl_DeleteEvents\fR(\fIdeleteProc, clientData\fR)
-.sp
-int
-\fBTcl_WaitForEvent\fR(\fItimePtr\fR)
-.sp
-\fBTcl_SetTimer\fR(\fItimePtr\fR)
-.sp
-int
-\fBTcl_ServiceAll\fR()
-.sp
-int
-\fBTcl_ServiceEvent\fR(\fIflags\fR)
-.sp
-int
-\fBTcl_GetServiceMode\fR()
-.sp
-int		
-\fBTcl_SetServiceMode\fR(\fImode\fR)
-.VE
-
-.SH ARGUMENTS
-.AS Tcl_EventDeleteProc milliseconds
-.AS Tcl_EventSetupProc *setupProc
-.AP Tcl_EventSetupProc *setupProc in
-Procedure to invoke to prepare for event wait in \fBTcl_DoOneEvent\fR.
-.AP Tcl_EventCheckProc *checkProc in
-Procedure for \fBTcl_DoOneEvent\fR to invoke after waiting for
-events.  Checks to see if any events have occurred and, if so,
-queues them.
-.AP ClientData clientData in
-Arbitrary one-word value to pass to \fIsetupProc\fR, \fIcheckProc\fR, or
-\fIdeleteProc\fR.
-.AP Tcl_Time *timePtr in
-Indicates the maximum amount of time to wait for an event.  This
-is specified as an interval (how long to wait), not an absolute
-time (when to wakeup).  If the pointer passed to \fBTcl_WaitForEvent\fR
-is NULL, it means there is no maximum wait time:  wait forever if
-necessary.
-.AP Tcl_Event *evPtr in
-An event to add to the event queue.  The storage for the event must
-have been allocated by the caller using \fBTcl_Alloc\fR or \fBckalloc\fR.
-.AP Tcl_QueuePosition position in
-Where to add the new event in the queue:  \fBTCL_QUEUE_TAIL\fR,
-\fBTCL_QUEUE_HEAD\fR, or \fBTCL_QUEUE_MARK\fR.
-.AP int flags in
-What types of events to service.  These flags are the same as those
-passed to \fBTcl_DoOneEvent\fR.
-.AP Tcl_EventDeleteProc *deleteProc in
-Procedure to invoke for each queued event in \fBTcl_DeleteEvents\fR.
-.VS
-.AP int mode in
-Inidicates whether events should be serviced by \fBTcl_ServiceAll\fR.
-Must be one of \fBTCL_SERVICE_NONE\fR or \fBTCL_SERVICE_ALL\fR.
-.VE
-.BE
-
-.SH INTRODUCTION
-.PP
-.VS
-The interfaces described here are used to customize the Tcl event
-loop.  The two most common customizations are to add new sources of
-events and to merge Tcl's event loop with some other event loop, such
-as one provided by an application in which Tcl is embedded.  Each of
-these tasks is described in a separate section below.
-.VE
-.PP
-The procedures in this manual entry are the building blocks out of which
-the Tcl event notifier is constructed.  The event notifier is the lowest
-layer in the Tcl event mechanism.  It consists of three things:
-.IP [1]
-Event sources: these represent the ways in which events can be
-generated.  For example, there is a timer event source that implements
-the \fBTcl_CreateTimerHandler\fR procedure and the \fBafter\fR
-command, and there is a file event source that implements the
-\fBTcl_CreateFileHandler\fR procedure on Unix systems.  An event
-source must work with the notifier to detect events at the right
-times, record them on the event queue, and eventually notify
-higher-level software that they have occurred.  The procedures
-\fBTcl_CreateEventSource\fR, \fBTcl_DeleteEventSource\fR,
-and \fBTcl_SetMaxBlockTime\fR, \fBTcl_QueueEvent\fR, and
-\fBTcl_DeleteEvents\fR are used primarily by event sources.
-.IP [2]
-The event queue: there is a single queue for the whole application,
-containing events that have been detected but not yet serviced.  Event
-sources place events onto the queue so that they may be processed in
-order at appropriate times during the event loop. The event queue
-guarantees a fair discipline of event handling, so that no event
-source can starve the others.  It also allows events to be saved for
-servicing at a future time.
-.VS
-\fBTcl_QueueEvent\fR is used (primarily
-by event sources) to add events to the event queue and 
-\fBTcl_DeleteEvents\fR is used to remove events from the queue without
-processing them.
-.IP [3]
-The event loop: in order to detect and process events, the application
-enters a loop that waits for events to occur, places them on the event
-queue, and then processes them.  Most applications will do this by
-calling the procedure \fBTcl_DoOneEvent\fR, which is described in a
-separate manual entry.
-.PP
-Most Tcl applications need not worry about any of the internals of
-the Tcl notifier.  However, the notifier now has enough flexibility
-to be retargeted either for a new platform or to use an external event
-loop (such as the Motif event loop, when Tcl is embedded in a Motif
-application).  The procedures \fBTcl_WaitForEvent\fR and
-\fBTcl_SetTimer\fR are normally implemented by Tcl, but may be
-replaced with new versions to retarget the notifier (the \fBTcl_Sleep\fR,
-\fBTcl_CreateFileHandler\fR, and \fBTcl_DeleteFileHandler\fR must
-also be replaced; see CREATING A NEW NOTIFIER below for details).
-The procedures \fBTcl_ServiceAll\fR, \fBTcl_ServiceEvent\fR,
-\fBTcl_GetServiceMode\fR, and \fBTcl_SetServiceMode\fR are provided
-to help connect Tcl's event loop to an external event loop such as
-Motif's.
-.SH "NOTIFIER BASICS"
-.VE
-.PP
-The easiest way to understand how the notifier works is to consider
-what happens when \fBTcl_DoOneEvent\fR is called.
-\fBTcl_DoOneEvent\fR is passed a \fIflags\fR argument that indicates
-what sort of events it is OK to process and also whether or not to
-block if no events are ready.  \fBTcl_DoOneEvent\fR does the following
-things:
-.IP [1]
-Check the event queue to see if it contains any events that can
-be serviced.  If so, service the first possible event, remove it
-.VS
-from the queue, and return.  It does this by calling
-\fBTcl_ServiceEvent\fR and passing in the \fIflags\fR argument.
-.VE
-.IP [2]
-Prepare to block for an event.  To do this, \fBTcl_DoOneEvent\fR
-invokes a \fIsetup procedure\fR in each event source.
-The event source will perform event-source specific initialization and
-.VS
-possibly call \fBTcl_SetMaxBlockTime\fR to limit how long
-.VE
-\fBTcl_WaitForEvent\fR will block if no new events occur.
-.IP [3]
-Call \fBTcl_WaitForEvent\fR.  This procedure is implemented differently
-on different platforms;  it waits for an event to occur, based on the
-information provided by the event sources.
-It may cause the application to block if \fItimePtr\fR specifies
-an interval other than 0.
-\fBTcl_WaitForEvent\fR returns when something has happened,
-such as a file becoming readable or the interval given by \fItimePtr\fR
-expiring.  If there are no events for \fBTcl_WaitForEvent\fR to
-wait for, so that it would block forever, then it returns immediately
-and \fBTcl_DoOneEvent\fR returns 0.
-.IP [4]
-Call a \fIcheck procedure\fR in each event source.  The check
-procedure determines whether any events of interest to this source
-occurred.  If so, the events are added to the event queue.
-.IP [5]
-Check the event queue to see if it contains any events that can
-be serviced.  If so, service the first possible event, remove it
-from the queue, and return.
-.IP [6]
-See if there are idle callbacks pending. If so, invoke all of them and
-return.
-.IP [7]
-Either return 0 to indicate that no events were ready, or go back to
-step [2] if blocking was requested by the caller.
-
-.SH "CREATING A NEW EVENT SOURCE"
-.PP
-An event source consists of three procedures invoked by the notifier,
-plus additional C procedures that are invoked by higher-level code
-to arrange for event-driven callbacks.  The three procedures called
-by the notifier consist of the setup and check procedures described
-above, plus an additional procedure that is invoked when an event
-is removed from the event queue for servicing.
-.PP
-The procedure \fBTcl_CreateEventSource\fR creates a new event source.
-Its arguments specify the setup procedure and check procedure for
-the event source.
-\fISetupProc\fR should match the following prototype:
-.CS
-typedef void Tcl_EventSetupProc(
-	ClientData \fIclientData\fR,
-	int \fIflags\fR);
-.CE
-The \fIclientData\fR argument will be the same as the \fIclientData\fR
-argument to \fBTcl_CreateEventSource\fR;  it is typically used to
-point to private information managed by the event source.
-The \fIflags\fR argument will be the same as the \fIflags\fR
-argument passed to \fBTcl_DoOneEvent\fR except that it will never
-be 0 (\fBTcl_DoOneEvent\fR replaces 0 with \fBTCL_ALL_EVENTS\fR).
-\fIFlags\fR indicates what kinds of events should be considered;
-if the bit corresponding to this event source isn't set, the event
-source should return immediately without doing anything.  For
-example, the file event source checks for the \fBTCL_FILE_EVENTS\fR
-bit.
-.PP
-\fISetupProc\fR's job is to make sure that the application wakes up
-when events of the desired type occur.  This is typically done in a
-platform-dependent fashion.  For example, under Unix an event source
-might call \fBTcl_CreateFileHandler\fR; under Windows it might
-request notification with a Windows event.  For timer-driven event
-sources such as timer events or any polled event, the event source
-can call \fBTcl_SetMaxBlockTime\fR to force the application to wake
-up after a specified time even if no events have occurred.
-.VS
-If no event source calls \fBTcl_SetMaxBlockTime\fR
-then \fBTcl_WaitForEvent\fR will wait as long as necessary for an
-event to occur; otherwise, it will only wait as long as the shortest
-interval passed to \fBTcl_SetMaxBlockTime\fR by one of the event
-sources.  If an event source knows that it already has events ready to
-report, it can request a zero maximum block time.  For example, the
-setup procedure for the X event source looks to see if there are
-events already queued.  If there are, it calls
-\fBTcl_SetMaxBlockTime\fR with a 0 block time so that
-\fBTcl_WaitForEvent\fR does not block if there is no new data on the X
-connection.
-.VE
-The \fItimePtr\fR argument to \fBTcl_WaitForEvent\fR points to
-a structure that describes a time interval in seconds and
-microseconds:
-.CS
-typedef struct Tcl_Time {
-	long \fIsec\fR;
-	long \fIusec\fR;
-} Tcl_Time;
-.CE
-The \fIusec\fR field should be less than 1000000.
-.PP
-.VS
-Information provided to \fBTcl_SetMaxBlockTime\fR
-is only used for the next call to \fBTcl_WaitForEvent\fR; it is
-discarded after \fBTcl_WaitForEvent\fR returns.
-.VE
-The next time an event wait is done each of the event sources'
-setup procedures will be called again, and they can specify new
-information for that event wait.
-.PP
-.VS
-If the application uses an external event loop rather than
-\fBTcl_DoOneEvent\fR, the event sources may need to call
-\fBTcl_SetMaxBlockTime\fR at other times.  For example, if a new event
-handler is registered that needs to poll for events, the event source
-may call \fBTcl_SetMaxBlockTime\fR to set the block time to zero to
-force the external event loop to call Tcl.  In this case,
-\fBTcl_SetMaxBlockTime\fR invokes \fBTcl_SetTimer\fR with the shortest
-interval seen since the last call to \fBTcl_DoOneEvent\fR or
-\fBTcl_ServiceAll\fR.
-.PP
-In addition to the generic procedure \fBTcl_SetMaxBlockTime\fR, other
-platform-specific procedures may also be available for
-\fIsetupProc\fR, if there is additional information needed by
-\fBTcl_WaitForEvent\fR on that platform.  For example, on Unix systems
-the \fBTcl_CreateFileHandler\fR interface can be used to wait for file events.
-.VE
-.PP
-The second procedure provided by each event source is its check
-procedure, indicated by the \fIcheckProc\fR argument to
-\fBTcl_CreateEventSource\fR.  \fICheckProc\fR must match the
-following prototype:
-.CS
-typedef void Tcl_EventCheckProc(
-	ClientData \fIclientData\fR,
-	int \fIflags\fR);
-.CE
-The arguments to this procedure are the same as those for \fIsetupProc\fR.
-\fBCheckProc\fR is invoked by \fBTcl_DoOneEvent\fR after it has waited
-for events.  Presumably at least one event source is now prepared to
-queue an event.  \fBTcl_DoOneEvent\fR calls each of the event sources
-in turn, so they all have a chance to queue any events that are ready.
-The check procedure does two things.  First, it must see if any events
-have triggered.  Different event sources do this in different ways.
-.PP
-If an event source's check procedure detects an interesting event, it
-must add the event to Tcl's event queue.  To do this, the event source
-calls \fBTcl_QueueEvent\fR.  The \fIevPtr\fR argument is a pointer to
-a dynamically allocated structure containing the event (see below for
-more information on memory management issues).  Each event source can
-define its own event structure with whatever information is relevant
-to that event source.  However, the first element of the structure
-must be a structure of type \fBTcl_Event\fR, and the address of this
-structure is used when communicating between the event source and the
-rest of the notifier.  A \fBTcl_Event\fR has the following definition:
-.CS
-typedef struct Tcl_Event {
-    Tcl_EventProc *\fIproc\fR;
-    struct Tcl_Event *\fInextPtr\fR;
-};
-.CE
-The event source must fill in the \fIproc\fR field of
-the event before calling \fBTcl_QueueEvent\fR.
-The \fInextPtr\fR is used to link together the events in the queue
-and should not be modified by the event source.
-.PP
-An event may be added to the queue at any of three positions, depending
-on the \fIposition\fR argument to \fBTcl_QueueEvent\fR:
-.IP \fBTCL_QUEUE_TAIL\fR 24
-Add the event at the back of the queue, so that all other pending
-events will be serviced first.  This is almost always the right
-place for new events.
-.IP \fBTCL_QUEUE_HEAD\fR 24
-Add the event at the front of the queue, so that it will be serviced
-before all other queued events.
-.IP \fBTCL_QUEUE_MARK\fR 24
-Add the event at the front of the queue, unless there are other
-events at the front whose position is \fBTCL_QUEUE_MARK\fR;  if so,
-add the new event just after all other \fBTCL_QUEUE_MARK\fR events.
-This value of \fIposition\fR is used to insert an ordered sequence of
-events at the front of the queue, such as a series of
-Enter and Leave events synthesized during a grab or ungrab operation
-in Tk.
-.PP
-.VS
-When it is time to handle an event from the queue (steps 1 and 4
-above) \fBTcl_ServiceEvent\fR will invoke the \fIproc\fR specified
-.VE
-in the first queued \fBTcl_Event\fR structure.
-\fIProc\fR must match the following prototype:
-.CS
-typedef int Tcl_EventProc(
-	Tcl_Event *\fIevPtr\fR,
-	int \fIflags\fR);
-.CE
-The first argument to \fIproc\fR is a pointer to the event, which will
-be the same as the first argument to the \fBTcl_QueueEvent\fR call that
-added the event to the queue.
-The second argument to \fIproc\fR is the \fIflags\fR argument for the
-.VS
-current call to \fBTcl_ServiceEvent\fR;  this is used by the event source
-.VE
-to return immediately if its events are not relevant.
-.PP
-It is up to \fIproc\fR to handle the event, typically by invoking
-one or more Tcl commands or C-level callbacks.
-Once the event source has finished handling the event it returns 1
-to indicate that the event can be removed from the queue.
-If for some reason the event source decides that the event cannot
-be handled at this time, it may return 0 to indicate that the event
-.VS
-should be deferred for processing later;  in this case \fBTcl_ServiceEvent\fR
-.VE
-will go on to the next event in the queue and attempt to service it.
-There are several reasons why an event source might defer an event.
-One possibility is that events of this type are excluded by the
-\fIflags\fR argument.
-For example, the file event source will always return 0 if the
-\fBTCL_FILE_EVENTS\fR bit isn't set in \fIflags\fR.
-Another example of deferring events happens in Tk if
-\fBTk_RestrictEvents\fR has been invoked to defer certain kinds
-of window events.
-.PP
-.VS
-When \fIproc\fR returns 1, \fBTcl_ServiceEvent\fR will remove the
-event from the event queue and free its storage.
-Note that the storage for an event must be allocated by
-the event source (using \fBTcl_Alloc\fR or the Tcl macro \fBckalloc\fR)
-before calling \fBTcl_QueueEvent\fR, but it
-will be freed by \fBTcl_ServiceEvent\fR, not by the event source.
-.PP
-\fBTcl_DeleteEvents\fR can be used to explicitly remove one or more
-events from the event queue.  \fBTcl_DeleteEvents\fR calls \fIproc\fR
-for each event in the queue, deleting those for with the procedure
-returns 1.  Events for which the procedure returns 0 are left in the
-queue.  \fIProc\fR should match the following prototype:
-.CS
-typedef int Tcl_EventDeleteProc(
-	Tcl_Event *\fIevPtr\fR,
-	ClientData \fIclientData\fR);
-.CE
-The \fIclientData\fR argument will be the same as the \fIclientData\fR
-argument to \fBTcl_DeleteEvents\fR; it is typically used to point to
-private information managed by the event source.  The \fIevPtr\fR will
-point to the next event in the queue.
-.VE
-
-.SH "CREATING A NEW NOTIFIER"
-.PP
-The notifier consists of all the procedures described in this manual
-entry, plus \fBTcl_DoOneEvent\fR and \fBTcl_Sleep\fR, which are
-.VS
-available on all platforms, and \fBTcl_CreateFileHandler\fR and
-\fBTcl_DeleteFileHandler\fR, which are Unix-specific.  Most of these
-procedures are generic, in that they are the same for all notifiers.
-However, five of the procedures are notifier-dependent:
-\fBTcl_SetTimer\fR, \fBTcl_Sleep\fR, \fBTcl_WaitForEvent\fR,
-\fBTcl_CreateFileHandler\fR and \fBTcl_DeleteFileHandler\fR.  To
-support a new platform or to integrate Tcl with an
-application-specific event loop, you must write new versions of these
-procedures.
-.PP
-\fBTcl_WaitForEvent\fR is the lowest-level procedure in the notifier;
-it is responsible for waiting for an ``interesting'' event to occur or
-for a given time to elapse.  Before \fBTcl_WaitForEvent\fR is invoked,
-each of the event sources' setup procedure will have been invoked.
-The \fItimePtr\fR argument to
-\fBTcl_WaitForEvent\fR gives the maximum time to block for an event,
-based on calls to \fBTcl_SetMaxBlockTime\fR made by setup procedures
-and on other information (such as the \fBTCL_DONT_WAIT\fR bit in
-\fIflags\fR).
-.PP
-Ideally, \fBTcl_WaitForEvent\fR should only wait for an event
-to occur; it should not actually process the event in any way.
-Later on, the
-event sources will process the raw events and create Tcl_Events on
-the event queue in their \fIcheckProc\fR procedures.
-However, on some platforms (such as Windows) this isn't possible;
-events may be processed in \fBTcl_WaitForEvent\fR, including queuing
-Tcl_Events and more (for example, callbacks for native widgets may be
-invoked).  The return value from \fBTcl_WaitForEvent\fR must be either
-0, 1, or \-1.  On platforms such as Windows where events get processed in
-\fBTcl_WaitForEvent\fR, a return value of 1 means that there may be more
-events still pending that haven't been processed.  This is a sign to the
-caller that it must call \fBTcl_WaitForEvent\fR again if it wants all
-pending events to be processed. A 0 return value means that calling
-\fBTcl_WaitForEvent\fR again will not have any effect: either this is a
-platform where \fBTcl_WaitForEvent\fR only waits without doing any event
-processing, or \fBTcl_WaitForEvent\fR knows for sure that there are no
-additional events to process (e.g. it returned because the time
-elapsed).  Finally, a return value of \-1 means that the event loop is
-no longer operational and the application should probably unwind and
-terminate.  Under Windows this happens when a WM_QUIT message is received;
-under Unix it happens when \fBTcl_WaitForEvent\fR would have waited
-forever because there were no active event sources and the timeout was
-infinite.
-.PP
-If the notifier will be used with an external event loop, then it must
-also support the \fBTcl_SetTimer\fR interface.  \fBTcl_SetTimer\fR is
-invoked by \fBTcl_SetMaxBlockTime\fR whenever the maximum blocking
-time has been reduced.  \fBTcl_SetTimer\fR should arrange for the
-external event loop to invoke \fBTcl_ServiceAll\fR after the specified
-interval even if no events have occurred.  This interface is needed
-because \fBTcl_WaitForEvent\fR isn't invoked when there is an external
-event loop.  If the
-notifier will only be used from \fBTcl_DoOneEvent\fR, then
-\fBTcl_SetTimer\fR need not do anything.
-.PP
-On Unix systems, the file event source also needs support from the
-notifier.  The file event source consists of the
-\fBTcl_CreateFileHandler\fR and \fBTcl_DeleteFileHandler\fR
-procedures, which are described elsewhere.
-.PP
-The \fBTcl_Sleep\fR and \fBTcl_DoOneEvent\fR interfaces are described
-elsewhere.
-.PP
-The easiest way to create a new notifier is to look at the code
-for an existing notifier, such as the files \fBunix/tclUnixNotfy.c\fR
-or \fBwin/tclWinNotify.c\fR in the Tcl source distribution.
-
-.SH "EXTERNAL EVENT LOOPS"
-.PP
-The notifier interfaces are designed so that Tcl can be embedded into
-applications that have their own private event loops.  In this case,
-the application does not call \fBTcl_DoOneEvent\fR except in the case
-of recursive event loops such as calls to the Tcl commands \fBupdate\fR
-or \fBvwait\fR.  Most of the time is spent in the external event loop
-of the application.  In this case the notifier must arrange for the
-external event loop to call back into Tcl when something
-happens on the various Tcl event sources.  These callbacks should
-arrange for appropriate Tcl events to be placed on the Tcl event queue.
-.PP
-Because the external event loop is not calling \fBTcl_DoOneEvent\fR on
-a regular basis, it is up to the notifier to arrange for
-\fBTcl_ServiceEvent\fR to be called whenever events are pending on the
-Tcl event queue.  The easiest way to do this is to invoke
-\fBTcl_ServiceAll\fR at the end of each callback from the external
-event loop.  This will ensure that all of the event sources are
-polled, any queued events are serviced, and any pending idle handlers
-are processed before returning control to the application.  In
-addition, event sources that need to poll for events can call
-\fBTcl_SetMaxBlockTime\fR to force the external event loop to call
-Tcl even if no events are available on the system event queue.
-.PP
-As a side effect of processing events detected in the main external
-event loop, Tcl may invoke \fBTcl_DoOneEvent\fR to start a recursive event
-loop in commands like \fBvwait\fR.  \fBTcl_DoOneEvent\fR will invoke
-the external event loop, which will result in callbacks as described
-in the preceding paragraph, which will result in calls to
-\fBTcl_ServiceAll\fR.  However, in these cases it is undesirable to
-service events in \fBTcl_ServiceAll\fR.  Servicing events there is
-unnecessary because control will immediately return to the
-external event loop and hence to \fBTcl_DoOneEvent\fR, which can
-service the events itself.  Furthermore, \fBTcl_DoOneEvent\fR is
-supposed to service only a single event, whereas \fBTcl_ServiceAll\fR
-normally services all pending events.  To handle this situation,
-\fBTcl_DoOneEvent\fR sets a flag for \fBTcl_ServiceAll\fR
-that causes it to return without servicing any events.
-This flag is called the \fIservice mode\fR;
-\fBTcl_DoOneEvent\fR restores it to its previous value before it returns.
-.PP
-In some cases, however, it may be necessary for \fBTcl_ServiceAll\fR
-to service events
-even when it has been invoked from \fBTcl_DoOneEvent\fR.  This happens
-when there is yet another recursive event loop invoked via an
-event handler called by \fBTcl_DoOneEvent\fR (such as one that is
-part of a native widget).  In this case, \fBTcl_DoOneEvent\fR may not
-have a chance to service events so \fBTcl_ServiceAll\fR must service
-them all.  Any recursive event loop that calls an external event
-loop rather than \fBTcl_DoOneEvent\fR must reset the service mode so
-that all events get processed in \fBTcl_ServiceAll\fR.  This is done
-by invoking the \fBTcl_SetServiceMode\fR procedure.  If
-\fBTcl_SetServiceMode\fR is passed \fBTCL_SERVICE_NONE\fR, then calls
-to \fBTcl_ServiceAll\fR will return immediately without processing any
-events.  If \fBTcl_SetServiceMode\fR is passed \fBTCL_SERVICE_ALL\fR,
-then calls to \fBTcl_ServiceAll\fR will behave normally.
-\fBTcl_SetServiceMode\fR returns the previous value of the service
-mode, which should be restored when the recursive loop exits.
-\fBTcl_GetServiceMode\fR returns the current value of the service
-mode.
-.VE
-
-.SH KEYWORDS
-event, notifier, event queue, event sources, file events, timer, idle, service mode
diff --git a/doc/OpenFileChnl.3 b/doc/OpenFileChnl.3
deleted file mode 100644
index c0d121c..0000000
--- a/doc/OpenFileChnl.3
+++ /dev/null
@@ -1,499 +0,0 @@
-'\"
-'\" Copyright (c) 1996-1997 Sun Microsystems, Inc.
-'\"
-'\" See the file "license.terms" for information on usage and redistribution
-'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\"
-'\" RCS: @(#) $Id: OpenFileChnl.3,v 1.2 1998/09/14 18:39:49 stanton Exp $
-.so man.macros
-.TH Tcl_OpenFileChannel 3 8.0 Tcl "Tcl Library Procedures"
-.BS
-'\" Note:  do not modify the .SH NAME line immediately below!
-.SH NAME
-Tcl_OpenFileChannel, Tcl_OpenCommandChannel, Tcl_MakeFileChannel, Tcl_GetChannel, Tcl_RegisterChannel, Tcl_UnregisterChannel, Tcl_Close, Tcl_Read, Tcl_Gets, Tcl_Write, Tcl_Flush, Tcl_Seek, Tcl_Tell, Tcl_Eof, Tcl_InputBlocked, Tcl_InputBuffered, Tcl_GetChannelOption, Tcl_SetChannelOption \- buffered I/O facilities using channels
-.SH SYNOPSIS
-.nf
-\fB#include <tcl.h>\fR
-.sp
-typedef ... Tcl_Channel;
-.sp
-Tcl_Channel
-\fBTcl_OpenFileChannel\fR(\fIinterp, fileName, mode, permissions\fR)
-.sp
-Tcl_Channel
-\fBTcl_OpenCommandChannel\fR(\fIinterp, argc, argv, flags\fR)
-.VS
-.sp
-Tcl_Channel
-\fBTcl_MakeFileChannel\fR(\fIhandle, readOrWrite\fR)
-.VE
-.sp
-Tcl_Channel
-\fBTcl_GetChannel\fR(\fIinterp, channelName, modePtr\fR)
-.sp
-void
-\fBTcl_RegisterChannel\fR(\fIinterp, channel\fR)
-.sp
-int
-\fBTcl_UnregisterChannel\fR(\fIinterp, channel\fR)
-.sp
-int
-\fBTcl_Close\fR(\fIinterp, channel\fR)
-.sp
-int
-\fBTcl_Read\fR(\fIchannel, buf, toRead\fR)
-.sp
-int
-\fBTcl_Gets\fR(\fIchannel, lineRead\fR)
-.sp
-int
-\fBTcl_GetsObj\fR(\fIchannel, lineObjPtr\fR)
-.sp
-int
-\fBTcl_Write\fR(\fIchannel, buf, toWrite\fR)
-.sp
-int
-\fBTcl_Flush\fR(\fIchannel\fR)
-.sp
-int
-\fBTcl_Seek\fR(\fIchannel, offset, seekMode\fR)
-.sp
-int
-\fBTcl_Tell\fR(\fIchannel\fR)
-.sp
-int
-\fBTcl_GetChannelOption\fR(\fIinterp, channel, optionName, optionValue\fR)
-.sp
-int
-\fBTcl_SetChannelOption\fR(\fIinterp, channel, optionName, newValue\fR)
-.sp
-int
-\fBTcl_Eof\fR(\fIchannel\fR)
-.sp
-int
-\fBTcl_InputBlocked\fR(\fIchannel\fR)
-.sp
-int
-\fBTcl_InputBuffered\fR(\fIchannel\fR)
-.sp
-.SH ARGUMENTS
-.AS Tcl_ChannelType newClientProcPtr in
-.AP Tcl_Interp *interp in
-Used for error reporting and to look up a channel registered in it.
-.AP char *fileName in
-The name of a local or network file.
-.AP char *mode in
-Specifies how the file is to be accessed.  May have any of the
-values allowed for the \fImode\fR argument to the Tcl
-\fBopen\fR command.
-For \fBTcl_OpenCommandChannel\fR, may be NULL.
-.AP int permissions in
-POSIX-style permission flags such as 0644.
-If a new file is created, these permissions will be set on the
-created file.
-.AP int argc in
-The number of elements in \fIargv\fR.
-.AP char **argv in
-Arguments for constructing a command pipeline.
-These values have the same meaning as the non-switch arguments
-to the Tcl \fBexec\fR command.
-.AP int flags in
-Specifies the disposition of the stdio handles in pipeline: OR-ed
-combination of \fBTCL_STDIN\fR, \fBTCL_STDOUT\fR, \fBTCL_STDERR\fR,
-and \fBTCL_ENFORCE_MODE\fR. If \fBTCL_STDIN\fR is set, stdin for
-the first child in the pipe is the pipe channel, otherwise it is the same
-as the standard input of the invoking process; likewise for
-\fBTCL_STDOUT\fR and \fBTCL_STDERR\fR. If \fBTCL_ENFORCE_MODE\fR is not set,
-then the pipe can redirect stdio handles to override the stdio handles for
-which \fBTCL_STDIN\fR, \fBTCL_STDOUT\fR and \fBTCL_STDERR\fR have been set.
-If it is set, then such redirections cause an error.
-.VS
-.AP ClientData handle in
-Operating system specific handle for I/O to a file. For Unix this is a
-file descriptor, for Windows it is a HANDLE.
-.AP int readOrWrite in
-OR-ed combination of \fBTCL_READABLE\fR and \fBTCL_WRITABLE\fR to indicate
-what operations are valid on \fIhandle\fR.
-.VE
-.AP int *modePtr out
-Points at an integer variable that will receive an OR-ed combination of
-\fBTCL_READABLE\fR and \fBTCL_WRITABLE\fR denoting whether the channel is
-open for reading and writing.
-.AP Tcl_Channel channel in
-A Tcl channel for input or output.  Must have been the return value
-from a procedure such as \fBTcl_OpenFileChannel\fR.
-.AP char *buf in
-An array of bytes in which to store channel input, or from which
-to read channel output.
-.AP int len in
-The length of the input or output.
-.AP int atEnd in
-If nonzero, store the input at the end of the input queue, otherwise store
-it at the head of the input queue.
-.AP int toRead in
-The number of bytes to read from the channel.
-.AP Tcl_DString *lineRead in
-A pointer to a Tcl dynamic string in which to store the line read from the
-channel.  Must have been initialized by the caller.  The line read
-will be appended to any data already in the dynamic string.
-.AP Tcl_Obj *linePtrObj in
-A pointer to a Tcl object in which to store the line read from the
-channel.  The line read will be appended to the current value of the
-object. 
-.AP int toWrite in
-The number of bytes to read from \fIbuf\fR and output to the channel.
-.AP int offset in
-How far to move the access point in the channel at which the next input or
-output operation will be applied, measured in bytes from the position
-given by \fIseekMode\fR.  May be either positive or negative.
-.AP int seekMode in
-Relative to which point to seek; used with \fIoffset\fR to calculate the new
-access point for the channel. Legal values are \fBSEEK_SET\fR,
-\fBSEEK_CUR\fR, and \fBSEEK_END\fR.
-.AP char *optionName in
-The name of an option applicable to this channel, such as \fB\-blocking\fR.
-May have any of the values accepted by the \fBfconfigure\fR command.
-.AP Tcl_DString *optionValue in
-Where to store the value of an option or a list of all options and their
-values. Must have been initialized by the caller.
-.AP char *newValue in
-New value for the option given by \fIoptionName\fR.
-.BE
-
-.SH DESCRIPTION
-.PP
-The Tcl channel mechanism provides a device-independent and
-platform-independent mechanism for performing buffered input
-and output operations on a variety of file, socket, and device
-types.
-The channel mechanism is extensible to new channel types, by
-providing a low level channel driver for the new type; the channel driver
-interface is described in the manual entry for \fBTcl_CreateChannel\fR. The
-channel mechanism provides a buffering scheme modelled after
-Unix's standard I/O, and it also allows for nonblocking I/O on
-channels.
-.PP
-The procedures described in this manual entry comprise the C APIs of the
-generic layer of the channel architecture. For a description of the channel
-driver architecture and how to implement channel drivers for new types of
-channels, see the manual entry for \fBTcl_CreateChannel\fR.
-
-.SH TCL_OPENFILECHANNEL
-.PP
-\fBTcl_OpenFileChannel\fR opens a file specified by \fIfileName\fR and
-returns a channel handle that can be used to perform input and output on
-the file. This API is modelled after the \fBfopen\fR procedure of
-the Unix standard I/O library.
-The syntax and meaning of all arguments is similar to those
-given in the Tcl \fBopen\fR command when opening a file.
-If an error occurs while opening the channel, \fBTcl_OpenFileChannel\fR
-returns NULL and records a POSIX error code that can be
-retrieved with \fBTcl_GetErrno\fR.
-In addition, if \fIinterp\fR is non-NULL, \fBTcl_OpenFileChannel\fR
-leaves an error message in \fIinterp->result\fR after any error.
-.PP
-The newly created channel is not registered in the supplied interpreter; to
-register it, use \fBTcl_RegisterChannel\fR, described below.
-If one of the standard channels, \fBstdin, stdout\fR or \fBstderr\fR was
-previously closed, the act of creating the new channel also assigns it as a
-replacement for the standard channel.
-
-.SH TCL_OPENCOMMANDCHANNEL
-.PP
-\fBTcl_OpenCommandChannel\fR provides a C-level interface to the
-functions of the \fBexec\fR and \fBopen\fR commands.
-It creates a sequence of subprocesses specified
-by the \fIargv\fR and \fIargc\fR arguments and returns a channel that can
-be used to communicate with these subprocesses.
-The \fIflags\fR argument indicates what sort of communication will
-exist with the command pipeline.
-.PP
-If the \fBTCL_STDIN\fR flag is set then the standard input for the
-first subprocess will be tied to the channel: writing to the channel
-will provide input to the subprocess.  If \fBTCL_STDIN\fR is not set,
-then standard input for the first subprocess will be the same as this
-application's standard input.  If \fBTCL_STDOUT\fR is set then
-standard output from the last subprocess can be read from the channel;
-otherwise it goes to this application's standard output.  If
-\fBTCL_STDERR\fR is set, standard error output for all subprocesses is
-returned to the channel and results in an error when the channel is
-closed; otherwise it goes to this application's standard error.  If
-\fBTCL_ENFORCE_MODE\fR is not set, then \fIargc\fR and \fIargv\fR can
-redirect the stdio handles to override \fBTCL_STDIN\fR,
-\fBTCL_STDOUT\fR, and \fBTCL_STDERR\fR; if it is set, then it is an
-error for argc and argv to override stdio channels for which
-\fBTCL_STDIN\fR, \fBTCL_STDOUT\fR, and \fBTCL_STDERR\fR have been set.
-.PP
-If an error occurs while opening the channel, \fBTcl_OpenCommandChannel\fR
-returns NULL and records a POSIX error code that can be retrieved with
-\fBTcl_GetErrno\fR.
-In addition, \fBTcl_OpenCommandChannel\fR leaves an error message in
-\fIinterp->result\fR if \fIinterp\fR is not NULL.
-.PP
-The newly created channel is not registered in the supplied interpreter; to
-register it, use \fBTcl_RegisterChannel\fR, described below.
-If one of the standard channels, \fBstdin, stdout\fR or \fBstderr\fR was
-previously closed, the act of creating the new channel also assigns it as a
-replacement for the standard channel.
-
-.SH TCL_MAKEFILECHANNEL
-.PP
-\fBTcl_MakeFileChannel\fR makes a \fBTcl_Channel\fR from an existing,
-platform-specific, file handle.
-The newly created channel is not registered in the supplied interpreter; to
-register it, use \fBTcl_RegisterChannel\fR, described below.
-If one of the standard channels, \fBstdin, stdout\fR or \fBstderr\fR was
-previously closed, the act of creating the new channel also assigns it as a
-replacement for the standard channel.
-
-.SH TCL_GETCHANNEL
-.PP
-\fBTcl_GetChannel\fR returns a channel given the \fIchannelName\fR used to
-create it with \fBTcl_CreateChannel\fR and a pointer to a Tcl interpreter in
-\fIinterp\fR. If a channel by that name is not registered in that interpreter,
-the procedure returns NULL. If the \fImode\fR argument is not NULL, it
-points at an integer variable that will receive an OR-ed combination of
-\fBTCL_READABLE\fR and \fBTCL_WRITABLE\fR describing whether the channel is
-open for reading and writing.
-
-.SH TCL_REGISTERCHANNEL
-.PP
-\fBTcl_RegisterChannel\fR adds a channel to the set of channels accessible
-in \fIinterp\fR. After this call, Tcl programs executing in that
-interpreter can refer to the channel in input or output operations using
-the name given in the call to \fBTcl_CreateChannel\fR.  After this call,
-the channel becomes the property of the interpreter, and the caller should
-not call \fBTcl_Close\fR for the channel; the channel will be closed
-automatically when it is unregistered from the interpreter.
-.PP
-Code executing outside of any Tcl interpreter can call
-\fBTcl_RegisterChannel\fR with \fIinterp\fR as NULL, to indicate that it
-wishes to hold a reference to this channel. Subsequently, the channel can
-be registered in a Tcl interpreter and it will only be closed when the
-matching number of calls to \fBTcl_UnregisterChannel\fR have been made.
-This allows code executing outside of any interpreter to safely hold a
-reference to a channel that is also registered in a Tcl interpreter.
-
-.SH TCL_UNREGISTERCHANNEL
-.PP
-\fBTcl_UnregisterChannel\fR removes a channel from the set of channels
-accessible in \fIinterp\fR. After this call, Tcl programs will no longer be
-able to use the channel's name to refer to the channel in that interpreter.
-If this operation removed the last registration of the channel in any
-interpreter, the channel is also closed and destroyed.
-.PP
-Code not associated with a Tcl interpreter can call
-\fBTcl_UnregisterChannel\fR with \fIinterp\fR as NULL, to indicate to Tcl
-that it no longer holds a reference to that channel. If this is the last
-reference to the channel, it will now be closed.
-
-.SH TCL_CLOSE
-.PP
-\fBTcl_Close\fR destroys the channel \fIchannel\fR, which must denote a
-currently open channel. The channel should not be registered in any
-interpreter when \fBTcl_Close\fR is called. Buffered output is flushed to
-the channel's output device prior to destroying the channel, and any
-buffered input is discarded.  If this is a blocking channel, the call does
-not return until all buffered data is successfully sent to the channel's
-output device.  If this is a nonblocking channel and there is buffered
-output that cannot be written without blocking, the call returns
-immediately; output is flushed in the background and the channel will be
-closed once all of the buffered data has been output.  In this case errors
-during flushing are not reported.
-.PP
-If the channel was closed successfully, \fBTcl_Close\fR returns \fBTCL_OK\fR.
-If an error occurs, \fBTcl_Close\fR returns \fBTCL_ERROR\fR and records a
-POSIX error code that can be retrieved with \fBTcl_GetErrno\fR.
-If the channel is being closed synchronously and an error occurs during
-closing of the channel and \fIinterp\fR is not NULL, an error message is
-left in \fIinterp->result\fR.
-.PP
-Note: it is not safe to call \fBTcl_Close\fR on a channel that has been
-registered using \fBTcl_RegisterChannel\fR; see the documentation for
-\fBTcl_RegisterChannel\fR, above, for details. If the channel has ever been
-given as the \fBchan\fR argument in a call to \fBTcl_RegisterChannel\fR,
-you should instead use \fBTcl_UnregisterChannel\fR, which will internally
-call \fBTcl_Close\fR when all calls to \fBTcl_RegisterChannel\fR have been
-matched by corresponding calls to \fBTcl_UnregisterChannel\fR.
-
-.SH TCL_READ
-.PP
-\fBTcl_Read\fR consumes up to \fItoRead\fR bytes of data from
-\fIchannel\fR and stores it at \fIbuf\fR.
-The return value of \fBTcl_Read\fR is the number of characters written
-at \fIbuf\fR.
-The buffer produced by \fBTcl_Read\fR is not NULL terminated. Its contents
-are valid from the zeroth position up to and excluding the position
-indicated by the return value.
-If an error occurs, the return value is -1 and \fBTcl_Read\fR records
-a POSIX error code that can be retrieved with \fBTcl_GetErrno\fR.
-.PP
-The return value may be smaller than the value of \fItoRead\fR, indicating
-that less data than requested was available, also called a \fIshort
-read\fR.
-In blocking mode, this can only happen on an end-of-file.
-In nonblocking mode, a short read can also occur if there is not
-enough input currently available:  \fBTcl_Read\fR returns a short
-count rather than waiting for more data.
-.PP
-If the channel is in blocking mode, a return value of zero indicates an end
-of file condition. If the channel is in nonblocking mode, a return value of
-zero indicates either that no input is currently available or an end of
-file condition. Use \fBTcl_Eof\fR and \fBTcl_InputBlocked\fR
-to tell which of these conditions actually occurred.
-.PP
-\fBTcl_Read\fR translates platform-specific end-of-line representations
-into the canonical \fB\en\fR internal representation according to the
-current end-of-line recognition mode. End-of-line recognition and the
-various platform-specific modes are described in the manual entry for the
-Tcl \fBfconfigure\fR command.
-
-.SH TCL_GETS AND TCL_GETSOBJ
-.PP
-\fBTcl_Gets\fR reads a line of input from a channel and appends all of
-the characters of the line except for the terminating end-of-line character(s)
-to the dynamic string given by \fIdsPtr\fR.
-The end-of-line character(s) are read and discarded.
-.PP
-If a line was successfully read, the return value is greater than or
-equal to zero, and it indicates the number of characters stored
-in the dynamic string.
-If an error occurs, \fBTcl_Gets\fR returns -1 and records a POSIX error
-code that can be retrieved with \fBTcl_GetErrno\fR.
-\fBTcl_Gets\fR also returns -1 if the end of the file is reached;
-the \fBTcl_Eof\fR procedure can be used to distinguish an error
-from an end-of-file condition.
-.PP
-If the channel is in nonblocking mode, the return value can also
-be -1 if no data was available or the data that was available
-did not contain an end-of-line character.
-When -1 is returned, the \fBTcl_InputBlocked\fR procedure may be
-invoked to determine if the channel is blocked because of input
-unavailability.
-.PP
-\fBTcl_GetsObj\fR is the same as \fBTcl_Gets\fR except the resulting
-characters are appended to a Tcl object \fBlineObjPtr\fR rather than a
-dynamic string.
-.SH TCL_WRITE
-.PP
-\fBTcl_Write\fR accepts \fItoWrite\fR bytes of data at \fIbuf\fR for output
-on \fIchannel\fR. This data may not appear on the output device
-immediately. If the data should appear immediately, call \fBTcl_Flush\fR
-after the call to \fBTcl_Write\fR, or set the \fB-buffering\fR option on
-the channel to \fBnone\fR. If you wish the data to appear as soon as an end
-of line is accepted for output, set the \fB\-buffering\fR option on the
-channel to \fBline\fR mode.
-.PP
-The \fItoWrite\fR argument specifies how many bytes of data are provided in
-the \fIbuf\fR argument. If it is negative, \fBTcl_Write\fR expects the data
-to be NULL terminated and it outputs everything up to the NULL.
-.PP
-The return value of \fBTcl_Write\fR is a count of how many
-characters were accepted for output to the channel. This is either equal to
-\fItoWrite\fR or -1 to indicate that an error occurred.
-If an error occurs, \fBTcl_Write\fR also records a POSIX error code
-that may be retrieved with \fBTcl_GetErrno\fR.
-.PP
-Newline characters in the output data are translated to platform-specific
-end-of-line sequences according to the \fB\-translation\fR option for
-the channel.
-
-.SH TCL_FLUSH
-.PP
-\fBTcl_Flush\fR causes all of the buffered output data for \fIchannel\fR
-to be written to its underlying file or device as soon as possible.
-If the channel is in blocking mode, the call does not return until
-all the buffered data has been sent to the channel or some error occurred.
-The call returns immediately if the channel is nonblocking; it starts
-a background flush that will write the buffered data to the channel
-eventually, as fast as the channel is able to absorb it.
-.PP
-The return value is normally \fBTCL_OK\fR.
-If an error occurs, \fBTcl_Flush\fR returns \fBTCL_ERROR\fR and
-records a POSIX error code that can be retrieved with \fBTcl_GetErrno\fR.
-
-.SH TCL_SEEK
-.PP
-\fBTcl_Seek\fR moves the access point in \fIchannel\fR where subsequent
-data will be read or written. Buffered output is flushed to the channel and
-buffered input is discarded, prior to the seek operation.
-.PP
-\fBTcl_Seek\fR normally returns the new access point.
-If an error occurs, \fBTcl_Seek\fR returns -1 and records a POSIX error
-code that can be retrieved with \fBTcl_GetErrno\fR.
-After an error, the access point may or may not have been moved.
-
-.SH TCL_TELL
-.PP
-\fBTcl_Tell\fR returns the current access point for a channel. The returned
-value is -1 if the channel does not support seeking.
-
-.SH TCL_GETCHANNELOPTION
-.PP
-\fBTcl_GetChannelOption\fR retrieves, in \fIdsPtr\fR, the value of one of
-the options currently in effect for a channel, or a list of all options and
-their values.  The \fIchannel\fR argument identifies the channel for which
-to query an option or retrieve all options and their values.
-If \fIoptionName\fR is not NULL, it is the name of the
-option to query; the option's value is copied to the Tcl dynamic string
-denoted by \fIoptionValue\fR. If
-\fIoptionName\fR is NULL, the function stores an alternating list of option
-names and their values in \fIoptionValue\fR, using a series of calls to
-\fBTcl_DStringAppendElement\fR. The various preexisting options and
-their possible values are described in the manual entry for the Tcl
-\fBfconfigure\fR command. Other options can be added by each channel type.
-These channel type specific options are described in the manual entry for
-the Tcl command that creates a channel of that type; for example, the
-additional options for TCP based channels are described in the manual entry
-for the Tcl \fBsocket\fR command.
-The procedure normally returns \fBTCL_OK\fR. If an error occurs, it returns
-\fBTCL_ERROR\fR and calls \fBTcl_SetErrno\fR to store an appropriate POSIX
-error code.
-
-.SH TCL_SETCHANNELOPTION
-.PP
-\fBTcl_SetChannelOption\fR sets a new value for an option on \fIchannel\fR.
-\fIOptionName\fR is the option to set and \fInewValue\fR is the value to
-set.
-The procedure normally returns \fBTCL_OK\fR.  If an error occurs,
-it returns \fBTCL_ERROR\fR;  in addition, if \fIinterp\fR is non-NULL,
-\fBTcl_SetChannelOption\fR leaves an error message in \fIinterp->result\fR.
-
-.SH TCL_EOF
-.PP
-\fBTcl_Eof\fR returns a nonzero value if \fIchannel\fR encountered
-an end of file during the last input operation.
-
-.SH TCL_INPUTBLOCKED
-.PP
-\fBTcl_InputBlocked\fR returns a nonzero value if \fIchannel\fR is in
-nonblocking mode and the last input operation returned less data than
-requested because there was insufficient data available.
-The call always returns zero if the channel is in blocking mode.
-
-.SH TCL_INPUTBUFFERED
-.PP
-\fBTcl_InputBuffered\fR returns the number of bytes of input currently
-buffered in the internal buffers for a channel. If the channel is not open
-for reading, this function always returns zero.
-
-.VS
-.SH "PLATFORM ISSUES"
-.PP
-The handles returned from \fBTcl_GetChannelHandle\fR depend on the
-platform and the channel type.  On Unix platforms, the handle is
-always a Unix file descriptor as returned from the \fBopen\fR system
-call.  On Windows platforms, the handle is a file \fBHANDLE\fR when
-the channel was created with \fBTcl_OpenFileChannel\fR,
-\fBTcl_OpenCommandChannel\fR, or \fBTcl_MakeFileChannel\fR.  Other
-channel types may return a different type of handle on Windows
-platforms.  On the Macintosh platform, the handle is a file reference
-number as returned from \fBHOpenDF\fR.
-.VE
-
-.SH "SEE ALSO"
-DString(3), fconfigure(n), filename(n), fopen(2), Tcl_CreateChannel(3)
-
-.SH KEYWORDS
-access point, blocking, buffered I/O, channel, channel driver, end of file,
-flush, input, nonblocking, output, read, seek, write
diff --git a/doc/regexp.n b/doc/regexp.n
deleted file mode 100644
index ed61c8d..0000000
--- a/doc/regexp.n
+++ /dev/null
@@ -1,145 +0,0 @@
-'\"
-'\" Copyright (c) 1993 The Regents of the University of California.
-'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
-'\"
-'\" See the file "license.terms" for information on usage and redistribution
-'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\" 
-'\" RCS: @(#) $Id: regexp.n,v 1.2 1998/09/14 18:39:54 stanton Exp $
-'\" 
-.so man.macros
-.TH regexp n "" Tcl "Tcl Built-In Commands"
-.BS
-'\" Note:  do not modify the .SH NAME line immediately below!
-.SH NAME
-regexp \- Match a regular expression against a string
-.SH SYNOPSIS
-\fBregexp \fR?\fIswitches\fR? \fIexp string \fR?\fImatchVar\fR? ?\fIsubMatchVar subMatchVar ...\fR?
-.BE
-
-.SH DESCRIPTION
-.PP
-Determines whether the regular expression \fIexp\fR matches part or
-all of \fIstring\fR and returns 1 if it does, 0 if it doesn't.
-.LP
-If additional arguments are specified after \fIstring\fR then they
-are treated as the names of variables in which to return
-information about which part(s) of \fIstring\fR matched \fIexp\fR.
-\fIMatchVar\fR will be set to the range of \fIstring\fR that
-matched all of \fIexp\fR.  The first \fIsubMatchVar\fR will contain
-the characters in \fIstring\fR that matched the leftmost parenthesized
-subexpression within \fIexp\fR, the next \fIsubMatchVar\fR will
-contain the characters that matched the next parenthesized
-subexpression to the right in \fIexp\fR, and so on.
-.LP
-If the initial arguments to \fBregexp\fR start with \fB\-\fR then
-they are treated as switches.  The following switches are
-currently supported:
-.TP 10
-\fB\-nocase\fR
-Causes upper-case characters in \fIstring\fR to be treated as
-lower case during the matching process.
-.TP 10
-\fB\-indices\fR
-Changes what is stored in the \fIsubMatchVar\fRs. 
-Instead of storing the matching characters from \fBstring\fR,
-each variable
-will contain a list of two decimal strings giving the indices
-in \fIstring\fR of the first and last characters in the matching
-range of characters.
-.TP 10
-\fB\-\|\-\fR
-Marks the end of switches.  The argument following this one will
-be treated as \fIexp\fR even if it starts with a \fB\-\fR.
-.LP
-If there are more \fIsubMatchVar\fR's than parenthesized
-subexpressions within \fIexp\fR, or if a particular subexpression
-in \fIexp\fR doesn't match the string (e.g. because it was in a
-portion of the expression that wasn't matched), then the corresponding
-\fIsubMatchVar\fR will be set to ``\fB\-1 \-1\fR'' if \fB\-indices\fR
-has been specified or to an empty string otherwise.
-
-.SH "REGULAR EXPRESSIONS"
-.PP
-Regular expressions are implemented using Henry Spencer's package
-(thanks, Henry!),
-and much of the description of regular expressions below is copied verbatim
-from his manual entry.
-.PP
-A regular expression is zero or more \fIbranches\fR, separated by ``|''.
-It matches anything that matches one of the branches.
-.PP
-A branch is zero or more \fIpieces\fR, concatenated.
-It matches a match for the first, followed by a match for the second, etc.
-.PP
-A piece is an \fIatom\fR possibly followed by ``*'', ``+'', or ``?''.
-An atom followed by ``*'' matches a sequence of 0 or more matches of the atom.
-An atom followed by ``+'' matches a sequence of 1 or more matches of the atom.
-An atom followed by ``?'' matches a match of the atom, or the null string.
-.PP
-An atom is a regular expression in parentheses (matching a match for the
-regular expression), a \fIrange\fR (see below), ``.''
-(matching any single character), ``^'' (matching the null string at the
-beginning of the input string), ``$'' (matching the null string at the
-end of the input string), a ``\e'' followed by a single character (matching
-that character), or a single character with no other significance
-(matching that character).
-.PP
-A \fIrange\fR is a sequence of characters enclosed in ``[]''.
-It normally matches any single character from the sequence.
-If the sequence begins with ``^'',
-it matches any single character \fInot\fR from the rest of the sequence.
-If two characters in the sequence are separated by ``\-'', this is shorthand
-for the full list of ASCII characters between them
-(e.g. ``[0-9]'' matches any decimal digit).
-To include a literal ``]'' in the sequence, make it the first character
-(following a possible ``^'').
-To include a literal ``\-'', make it the first or last character.
-
-.SH "CHOOSING AMONG ALTERNATIVE MATCHES"
-.PP
-In general there may be more than one way to match a regular expression
-to an input string.  For example, consider the command
-.CS
-\fBregexp  (a*)b*  aabaaabb  x  y\fR
-.CE
-Considering only the rules given so far, \fBx\fR and \fBy\fR could
-end up with the values \fBaabb\fR and \fBaa\fR, \fBaaab\fR and \fBaaa\fR,
-\fBab\fR and \fBa\fR, or any of several other combinations.
-To resolve this potential ambiguity \fBregexp\fR chooses among
-alternatives using the rule ``first then longest''.
-In other words, it considers the possible matches in order working
-from left to right across the input string and the pattern, and it
-attempts to match longer pieces of the input string before shorter
-ones.  More specifically, the following rules apply in decreasing
-order of priority:
-.IP [1]
-If a regular expression could match two different parts of an input string
-then it will match the one that begins earliest.
-.IP [2]
-If a regular expression contains \fB|\fR operators then the leftmost
-matching sub-expression is chosen.
-.IP [3]
-In \fB*\fR, \fB+\fR, and \fB?\fR constructs, longer matches are chosen
-in preference to shorter ones.
-.IP [4]
-In sequences of expression components the components are considered
-from left to right.
-.LP
-In the example from above, \fB(a*)b*\fR matches \fBaab\fR:  the \fB(a*)\fR
-portion of the pattern is matched first and it consumes the leading
-\fBaa\fR; then the \fBb*\fR portion of the pattern consumes the
-next \fBb\fR.  Or, consider the following example:
-.CS
-\fBregexp  (ab|a)(b*)c  abc  x  y  z\fR
-.CE
-After this command \fBx\fR will be \fBabc\fR, \fBy\fR will be
-\fBab\fR, and \fBz\fR will be an empty string.
-Rule 4 specifies that \fB(ab|a)\fR gets first shot at the input
-string and Rule 2 specifies that the \fBab\fR sub-expression
-is checked before the \fBa\fR sub-expression.
-Thus the \fBb\fR has already been claimed before the \fB(b*)\fR
-component is checked and \fB(b*)\fR must match an empty string.
-
-.SH KEYWORDS
-match, regular expression, string