Merge 8.7

20 files changed, 824 insertions, 849 deletions

diff --git a/doc/BoolObj.3 b/doc/BoolObj.3
index 9bbdc7e..c05048c 100644
--- a/doc/BoolObj.3
+++ b/doc/BoolObj.3
@@ -15,15 +15,15 @@ Tcl_NewBooleanObj, Tcl_SetBooleanObj, Tcl_GetBooleanFromObj \- store/retrieve bo
 \fB#include <tcl.h>\fR
 .sp
 Tcl_Obj *
-\fBTcl_NewBooleanObj\fR(\fIboolValue\fR)
+\fBTcl_NewBooleanObj\fR(\fIintValue\fR)
 .sp
-\fBTcl_SetBooleanObj\fR(\fIobjPtr, boolValue\fR)
+\fBTcl_SetBooleanObj\fR(\fIobjPtr, intValue\fR)
 .sp
 int
-\fBTcl_GetBooleanFromObj\fR(\fIinterp, objPtr, boolPtr\fR)
+\fBTcl_GetBooleanFromObj\fR(\fIinterp, objPtr, intPtr\fR)
 .SH ARGUMENTS
-.AS Tcl_Interp boolValue in/out
-.AP int boolValue in
+.AS Tcl_Interp intValue in/out
+.AP int intValue in
 Integer value to be stored as a boolean value in a Tcl_Obj.
 .AP Tcl_Obj *objPtr in/out
 Points to the Tcl_Obj in which to store, or from which to
@@ -32,7 +32,7 @@ retrieve a boolean value.
 If a boolean value cannot be retrieved,
 an error message is left in the interpreter's result value
 unless \fIinterp\fR is NULL.
-.AP int *boolPtr out
+.AP int *intPtr out
 Points to place where \fBTcl_GetBooleanFromObj\fR
 stores the boolean value (0 or 1) obtained from \fIobjPtr\fR.
 .BE
@@ -41,33 +41,33 @@ stores the boolean value (0 or 1) obtained from \fIobjPtr\fR.
 .PP
 These procedures are used to pass boolean values to and from
 Tcl as Tcl_Obj's.  When storing a boolean value into a Tcl_Obj,
-any non-zero integer value in \fIboolValue\fR is taken to be
+any non-zero integer value in \fIintValue\fR is taken to be
 the boolean value \fB1\fR, and the integer value \fB0\fR is
 taken to be the boolean value \fB0\fR.
 .PP
 \fBTcl_NewBooleanObj\fR creates a new Tcl_Obj, stores the boolean
-value \fIboolValue\fR in it, and returns a pointer to the new Tcl_Obj.
+value \fIintValue\fR in it, and returns a pointer to the new Tcl_Obj.
 The new Tcl_Obj has reference count of zero.
 .PP
 \fBTcl_SetBooleanObj\fR accepts \fIobjPtr\fR, a pointer to
 an existing Tcl_Obj, and stores in the Tcl_Obj \fI*objPtr\fR
-the boolean value \fIboolValue\fR.  This is a write operation
+the boolean value \fIintValue\fR.  This is a write operation
 on \fI*objPtr\fR, so \fIobjPtr\fR must be unshared.  Attempts to
 write to a shared Tcl_Obj will panic.  A successful write
-of \fIboolValue\fR into \fI*objPtr\fR implies the freeing of
+of \fIintValue\fR into \fI*objPtr\fR implies the freeing of
 any former value stored in \fI*objPtr\fR.
 .PP
 \fBTcl_GetBooleanFromObj\fR attempts to retrieve a boolean value
 from the value stored in \fI*objPtr\fR.
 If \fIobjPtr\fR holds a string value recognized by \fBTcl_GetBoolean\fR,
 then the recognized boolean value is written at the address given
-by \fIboolPtr\fR.
+by \fIintPtr\fR.
 If \fIobjPtr\fR holds any value recognized as
 a number by Tcl, then if that value is zero a 0 is written at
-the address given by \fIboolPtr\fR and if that
-value is non-zero a 1 is written at the address given by \fIboolPtr\fR.
+the address given by \fIintPtr\fR and if that
+value is non-zero a 1 is written at the address given by \fIintPtr\fR.
 In all cases where a value is written at the address given
-by \fIboolPtr\fR, \fBTcl_GetBooleanFromObj\fR returns \fBTCL_OK\fR.
+by \fIintPtr\fR, \fBTcl_GetBooleanFromObj\fR returns \fBTCL_OK\fR.
 If the value of \fIobjPtr\fR does not meet any of the conditions
 above, then \fBTCL_ERROR\fR is returned and an error message is
 left in the interpreter's result unless \fIinterp\fR is NULL.
diff --git a/doc/CrtObjCmd.3 b/doc/CrtObjCmd.3
index f15e277..8d10418 100644
--- a/doc/CrtObjCmd.3
+++ b/doc/CrtObjCmd.3
@@ -8,7 +8,7 @@
 .so man.macros
 .BS
 .SH NAME
-Tcl_CreateObjCommand, Tcl_DeleteCommand, Tcl_DeleteCommandFromToken, Tcl_GetCommandInfo, Tcl_GetCommandInfoFromToken, Tcl_SetCommandInfo, Tcl_SetCommandInfoFromToken, Tcl_GetCommandName, Tcl_GetCommandFullName, Tcl_GetCommandFromObj, Tcl_RegisterCommandTypeName, Tcl_GetCommandTypeName \- implement new commands in C
+Tcl_CreateObjCommand, Tcl_DeleteCommand, Tcl_DeleteCommandFromToken, Tcl_GetCommandInfo, Tcl_GetCommandInfoFromToken, Tcl_SetCommandInfo, Tcl_SetCommandInfoFromToken, Tcl_GetCommandName, Tcl_GetCommandFullName, Tcl_GetCommandFromObj \- implement new commands in C
 .SH SYNOPSIS
 .nf
 \fB#include <tcl.h>\fR
@@ -43,13 +43,6 @@ void
 Tcl_Command
 \fBTcl_GetCommandFromObj\fR(\fIinterp, objPtr\fR)
 .sp
-.VS "info cmdtype feature"
-void
-\fBTcl_RegisterCommandTypeName\fR(\fIproc, typeName\fR)
-.sp
-const char *
-\fBTcl_GetCommandTypeName\fR(\fItoken\fR)
-.VE "info cmdtype feature"
 .SH ARGUMENTS
 .AS Tcl_CmdDeleteProc *deleteProc in/out
 .AP Tcl_Interp *interp in
@@ -308,21 +301,6 @@ specified by the name in a \fBTcl_Obj\fR.
 The command name is resolved relative to the current namespace.
 Returns NULL if the command is not found.
 .PP
-.VS "info cmdtype feature"
-\fBTcl_RegisterCommandTypeName\fR is used to associate a name (the
-\fItypeName\fR argument) with a particular implementation function so that it
-can then be looked up with \fBTcl_GetCommandTypeName\fR, which in turn is
-called with a command token that information is wanted for and which returns
-the name of the type that was registered for the implementation function used
-for that command. (The lookup functionality is surfaced virtually directly in Tcl via
-\fBinfo cmdtype\fR.) If there is no function registered for a particular
-function, the result will be the string literal
-.QW \fBnative\fR .
-The registration of a name can be undone by registering a mapping to NULL
-instead. The result from \fBTcl_GetCommandTypeName\fR will be exactly that
-string which was registered, and not a copy; use of a compile-time constant
-string is \fIstrongly recommended\fR.
-.VE "info cmdtype feature"
 .SH "REFERENCE COUNT MANAGEMENT"
 .PP
 When the \fIproc\fR passed to \fBTcl_CreateObjCommand\fR is called,
diff --git a/doc/CrtTrace.3 b/doc/CrtTrace.3
index bf8587d..620c081 100644
--- a/doc/CrtTrace.3
+++ b/doc/CrtTrace.3
@@ -99,11 +99,7 @@ the Tcl interpreter will invoke the command.  Any other return code
 is treated as if the command returned that status, and the command is
 \fInot\fR invoked.
 .PP
-The \fIobjProc\fR callback must not modify \fIobjv\fR in any way.  It
-is, however, permissible to change the command by calling
-\fBTcl_SetCommandTokenInfo\fR prior to returning.  Any such change
-takes effect immediately, and the command is invoked with the new
-information.
+The \fIobjProc\fR callback must not modify \fIobjv\fR in any way.
 .PP
 Tracing will only occur for commands at nesting level less than
 or equal to the \fIlevel\fR parameter (i.e. the \fIlevel\fR
diff --git a/doc/Encoding.3 b/doc/Encoding.3
index c68070c..86c5a78 100644
--- a/doc/Encoding.3
+++ b/doc/Encoding.3
@@ -25,10 +25,16 @@ int
 char *
 \fBTcl_ExternalToUtfDString\fR(\fIencoding, src, srcLen, dstPtr\fR)
 .sp
+int
+\fBTcl_ExternalToUtfDStringEx\fR(\fIencoding, src, srcLen, flags, dstPtr\fR)
+.sp
 char *
 \fBTcl_UtfToExternalDString\fR(\fIencoding, src, srcLen, dstPtr\fR)
 .sp
 int
+\fBTcl_UtfToExternalDStringEx\fR(\fIencoding, src, srcLen, flags, dstPtr\fR)
+.sp
+int
 \fBTcl_ExternalToUtf\fR(\fIinterp, encoding, src, srcLen, flags, statePtr,
                   dst, dstLen, srcReadPtr, dstWrotePtr, dstCharsPtr\fR)
 .sp
@@ -108,7 +114,10 @@ byte is converted and then to reset to an initial state.
 \fBTCL_ENCODING_STOPONERROR\fR signifies that the conversion routine should
 return immediately upon reading a source character that does not exist in
 the target encoding; otherwise a default fallback character will
-automatically be substituted.
+automatically be substituted. The flag \fBTCL_ENCODING_NOCOMPLAIN\fR has
+no effect, it is reserved for Tcl 9.0. The flag \fBTCL_ENCODING_MODIFIED\fR makes
+\fBTcl_UtfToExternalDStringEx\fR and \fBTcl_UtfToExternal\fR produce the
+byte sequence \exC0\ex80 in stead of \ex00, for the utf-8/cesu-8 encoders.
 .AP Tcl_EncodingState *statePtr in/out
 Used when converting a (generally long or indefinite length) byte stream
 in a piece-by-piece fashion.  The conversion routine stores its current
@@ -208,6 +217,11 @@ When converting, if any of the characters in the source buffer cannot be
 represented in the target encoding, a default fallback character will be
 used.  The return value is a pointer to the value stored in the DString.
 .PP
+\fBTcl_ExternalToUtfDStringEx\fR is the same as \fBTcl_ExternalToUtfDString\fR,
+but it has an additional flags parameter.  The return value is the index of
+the first byte in the input string causing a conversion error.
+Or TCL_INDEX_NONE if all is OK.
+.PP
 \fBTcl_ExternalToUtf\fR converts a source buffer \fIsrc\fR from the specified
 \fIencoding\fR into UTF-8.  Up to \fIsrcLen\fR bytes are converted from the
 source buffer and up to \fIdstLen\fR converted bytes are stored in \fIdst\fR.
@@ -246,6 +260,11 @@ characters in the source buffer cannot be represented in the target
 encoding, a default fallback character will be used.  The return value is
 a pointer to the value stored in the DString.
 .PP
+\fBTcl_UtfToExternalDStringEx\fR is the same as \fBTcl_UtfToExternalDString\fR,
+but it has an additional flags parameter.  The return value is the index of
+the first byte of an utf-8 byte-sequence in the input string causing a
+conversion error. Or TCL_INDEX_NONE if all is OK.
+.PP
 \fBTcl_UtfToExternal\fR converts a source buffer \fIsrc\fR from UTF-8 into
 the specified \fIencoding\fR.  Up to \fIsrcLen\fR bytes are converted from
 the source buffer and up to \fIdstLen\fR converted bytes are stored in
diff --git a/doc/GetIndex.3 b/doc/GetIndex.3
index a788848..1169c6c 100644
--- a/doc/GetIndex.3
+++ b/doc/GetIndex.3
@@ -54,10 +54,12 @@ Null-terminated string describing what is being looked up, such as
 .AP int flags in
 OR-ed combination of bits providing additional information for
 operation.  The only bits that are currently defined are \fBTCL_EXACT\fR
-and \fBTCL_INDEX_TEMP_TABLE\fR.
-.AP int *indexPtr out
-The index of the string in \fItablePtr\fR that matches the value of
-\fIobjPtr\fR is returned here.
+, \fBTCL_INDEX_TEMP_TABLE\fR, and \fBTCL_INDEX_NULL_OK\fR.
+.AP enum|char|short|int|long *indexPtr out
+If not (int *)NULL, the index of the string in \fItablePtr\fR that
+matches the value of \fIobjPtr\fR is returned here. The variable can
+be any integer type, signed or unsigned, char, short, long or
+long long. It can also be an enum.
 .BE
 .SH DESCRIPTION
 .PP
@@ -70,8 +72,8 @@ the strings in \fItablePtr\fR to find a match.  A match occurs if
 \fItablePtr\fR, or if it is a non-empty unique abbreviation
 for exactly one of the strings in \fItablePtr\fR and the
 \fBTCL_EXACT\fR flag was not specified; in either case
-the index of the matching entry is stored at \fI*indexPtr\fR
-and \fBTCL_OK\fR is returned.
+\fBTCL_OK\fR is returned. If \fIindexPtr\fR is not NULL the index
+of the matching entry is stored at \fI*indexPtr\fR.
 .PP
 If there is no matching entry,
 \fBTCL_ERROR\fR is returned and an error message is left in \fIinterp\fR's
@@ -91,7 +93,9 @@ operation.  Note: \fBTcl_GetIndexFromObj\fR assumes that the entries
 in \fItablePtr\fR are static: they must not change between
 invocations.  This caching mechanism can be disallowed by specifying
 the \fBTCL_INDEX_TEMP_TABLE\fR flag.
-If the value of \fIobjPtr\fR is the empty string,
+If the \fBTCL_INDEX_NULL_OK\fR flag was specified, objPtr is allowed
+to be NULL or the empty string. The resulting index is -1.
+Otherwise, if the value of \fIobjPtr\fR is the empty string,
 \fBTcl_GetIndexFromObj\fR will treat it as a non-matching value
 and return \fBTCL_ERROR\fR.
 .PP
diff --git a/doc/GetInt.3 b/doc/GetInt.3
index eba549d..4b486de 100644
--- a/doc/GetInt.3
+++ b/doc/GetInt.3
@@ -21,7 +21,7 @@ int
 \fBTcl_GetDouble\fR(\fIinterp, src, doublePtr\fR)
 .sp
 int
-\fBTcl_GetBoolean\fR(\fIinterp, src, boolPtr\fR)
+\fBTcl_GetBoolean\fR(\fIinterp, src, intPtr\fR)
 .SH ARGUMENTS
 .AS Tcl_Interp *doublePtr out
 .AP Tcl_Interp *interp in
@@ -33,8 +33,6 @@ Points to place to store integer value converted from \fIsrc\fR.
 .AP double *doublePtr out
 Points to place to store double-precision floating-point
 value converted from \fIsrc\fR.
-.AP int *boolPtr out
-Points to place to store boolean value (0 or 1) converted from \fIsrc\fR.
 .BE
 
 .SH DESCRIPTION
@@ -48,7 +46,7 @@ third argument.  If all goes well, each of the procedures returns
 \fBTCL_OK\fR.  If \fIsrc\fR does not have the proper syntax for the
 desired type then \fBTCL_ERROR\fR is returned, an error message is left
 in the interpreter's result, and nothing is stored at *\fIintPtr\fR
-or *\fIdoublePtr\fR or *\fIboolPtr\fR.
+or *\fIdoublePtr\fR.
 .PP
 \fBTcl_GetInt\fR expects \fIsrc\fR to consist of a collection
 of integer digits, optionally signed and optionally preceded and
@@ -94,9 +92,9 @@ inter-digit separator be present.
 \fBTcl_GetBoolean\fR expects \fIsrc\fR to specify a boolean
 value.  If \fIsrc\fR is any of \fB0\fR, \fBfalse\fR,
 \fBno\fR, or \fBoff\fR, then \fBTcl_GetBoolean\fR stores a zero
-value at \fI*boolPtr\fR.
+value at \fI*intPtr\fR.
 If \fIsrc\fR is any of \fB1\fR, \fBtrue\fR, \fByes\fR, or \fBon\fR,
-then 1 is stored at \fI*boolPtr\fR.
+then 1 is stored at \fI*intPtr\fR.
 Any of these values may be abbreviated, and upper-case spellings
 are also acceptable.
 
diff --git a/doc/LinkVar.3 b/doc/LinkVar.3
index 92e7d03..3a41582 100644
--- a/doc/LinkVar.3
+++ b/doc/LinkVar.3
@@ -53,7 +53,7 @@ used.
 .sp
 .VS "TIP 312"
 In \fBTcl_LinkArray\fR, the additional linked types \fBTCL_LINK_CHARS\fR and
-\fBTCL_LINK_BYTES\fR may be used.
+\fBTCL_LINK_BINARY\fR may be used.
 .VE "TIP 312"
 .sp
 All the above for both functions may be
@@ -146,11 +146,11 @@ prefix) are accepted as if they are valid too.
 .RS
 .PP
 .VS "TIP 312"
-If using an array of these, consider using \fBTCL_LINK_BYTES\fR instead.
+If using an array of these, consider using \fBTCL_LINK_BINARY\fR instead.
 .VE "TIP 312"
 .RE
 .TP
-\fBTCL_LINK_BYTES\fR
+\fBTCL_LINK_BINARY\fR
 .VS "TIP 312"
 The C array is of type \fBunsigned char *\fR and is mapped into Tcl
 as a bytearray.
diff --git a/doc/ListObj.3 b/doc/ListObj.3
index 67721c9..c5c1dc7 100644
--- a/doc/ListObj.3
+++ b/doc/ListObj.3
@@ -28,7 +28,7 @@ int
 \fBTcl_ListObjGetElements\fR(\fIinterp, listPtr, objcPtr, objvPtr\fR)
 .sp
 int
-\fBTcl_ListObjLength\fR(\fIinterp, listPtr, intPtr\fR)
+\fBTcl_ListObjLength\fR(\fIinterp, listPtr, lengthPtr\fR)
 .sp
 int
 \fBTcl_ListObjIndex\fR(\fIinterp, listPtr, index, objPtrPtr\fR)
@@ -76,7 +76,7 @@ An array of pointers to values.
 \fBTcl_NewListObj\fR will insert these values into a new list value
 and \fBTcl_ListObjReplace\fR will insert them into an existing \fIlistPtr\fR.
 Each value will become a separate list element.
-.AP int *intPtr out
+.AP int *lengthPtr out
 Points to location where \fBTcl_ListObjLength\fR
 stores the length of the list.
 .AP int index in
@@ -162,7 +162,7 @@ Otherwise it returns \fBTCL_OK\fR after storing the count and array pointer.
 .PP
 \fBTcl_ListObjLength\fR returns the number of elements in the list value
 referenced by \fIlistPtr\fR.
-It returns this count by storing an integer in the address \fIintPtr\fR.
+It returns this count by storing an integer in the address \fIlengthPtr\fR.
 If the value is not already a list value,
 \fBTcl_ListObjLength\fR will attempt to convert it to one;
 if the conversion fails, it returns \fBTCL_ERROR\fR
diff --git a/doc/Notifier.3 b/doc/Notifier.3
index ec9f910..7cb02f6 100644
--- a/doc/Notifier.3
+++ b/doc/Notifier.3
@@ -90,9 +90,10 @@ 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
+.AP int position in
 Where to add the new event in the queue:  \fBTCL_QUEUE_TAIL\fR,
-\fBTCL_QUEUE_HEAD\fR, or \fBTCL_QUEUE_MARK\fR.
+\fBTCL_QUEUE_HEAD\fR, \fBTCL_QUEUE_MARK\fR, and whether to do
+an alert if the queue is empty: \fBTCL_QUEUE_ALERT_IF_EMPTY\fR.
 .AP Tcl_ThreadId threadId in
 A unique identifier for a thread.
 .AP Tcl_EventDeleteProc *deleteProc in
@@ -103,7 +104,7 @@ passed to \fBTcl_DoOneEvent\fR.
 .AP int mode in
 Indicates whether events should be serviced by \fBTcl_ServiceAll\fR.
 Must be one of \fBTCL_SERVICE_NONE\fR or \fBTCL_SERVICE_ALL\fR.
-.AP Tcl_NotifierProcs* notifierProcPtr in
+.AP const Tcl_NotifierProcs* notifierProcPtr in
 Structure of function pointers describing notifier procedures that are
 to replace the ones installed in the executable.  See
 \fBREPLACING THE NOTIFIER\fR for details.
@@ -340,14 +341,14 @@ 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
+.IP \fBTCL_QUEUE_TAIL\fR 32
 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
+.IP \fBTCL_QUEUE_HEAD\fR 32
 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
+.IP \fBTCL_QUEUE_MARK\fR 32
 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.
@@ -355,6 +356,10 @@ 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.
+.IP \fBTCL_QUEUE_ALERT_IF_EMPTY\fR 32
+When used in \fBTcl_ThreadQueueEvent\fR
+arranges for an automatic call of \fBTcl_ThreadAlert\fR when the queue was
+empty.
 .PP
 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
diff --git a/doc/StringObj.3 b/doc/StringObj.3
index 772073e..1b04dd4 100644
--- a/doc/StringObj.3
+++ b/doc/StringObj.3
@@ -111,15 +111,17 @@ If negative, all characters up to the first null character are used.
 The index of the Unicode character to return.
 .AP int first in
 The index of the first Unicode character in the Unicode range to be
-returned as a new value.
+returned as a new value. If negative, behave the same as if the
+value was 0.
 .AP int last in
 The index of the last Unicode character in the Unicode range to be
-returned as a new value.
+returned as a new value. If negative, take all characters up to
+the last one available.
 .AP Tcl_Obj *objPtr in/out
 Points to a value to manipulate.
 .AP Tcl_Obj *appendObjPtr in
 The value to append to \fIobjPtr\fR in \fBTcl_AppendObjToObj\fR.
-.AP size_t | int *lengthPtr out
+.AP int *lengthPtr out
 The location where \fBTcl_GetStringFromObj\fR will store the length
 of a value's string representation. May be (int *)NULL when not used.
 .AP "const char" *string in
diff --git a/doc/Tcl_Main.3 b/doc/Tcl_Main.3
index 904ecbe..6a37cda 100644
--- a/doc/Tcl_Main.3
+++ b/doc/Tcl_Main.3
@@ -85,8 +85,10 @@ that does nothing but invoke \fBTcl_Main\fR.
 .PP
 \fBTcl_Main\fR is not provided by the public interface of Tcl's
 stub library.  Programs that call \fBTcl_Main\fR must be linked
-against the standard Tcl library.  Extensions (stub-enabled or
-not) are not intended to call \fBTcl_Main\fR.
+against the standard Tcl library.  If the standard Tcl library is
+a dll (so, not a static .lib/.a) , then the program must be linked
+against the stub library as well. Extensions
+(stub-enabled or not) are not intended to call \fBTcl_Main\fR.
 .PP
 \fBTcl_Main\fR is not thread-safe.  It should only be called by
 a single main thread of a multi-threaded application.  This
diff --git a/doc/Utf.3 b/doc/Utf.3
index f1aca4c..b0c7f64 100644
--- a/doc/Utf.3
+++ b/doc/Utf.3
@@ -8,7 +8,7 @@
 .so man.macros
 .BS
 .SH NAME
-Tcl_UniChar, Tcl_UniCharToUtf, Tcl_UtfToUniChar, Tcl_UtfToChar16, Tcl_UtfToWChar, Tcl_UniCharToUtfDString, Tcl_UtfToUniCharDString, Tcl_Char16ToUtfDString, Tcl_UtfToWCharDString, Tcl_UtfToChar16DString, Tcl_UniCharLen, Tcl_UniCharNcmp, Tcl_UniCharNcasecmp, Tcl_UniCharCaseMatch, Tcl_UtfNcmp, Tcl_UtfNcasecmp, Tcl_UtfCharComplete, Tcl_NumUtfChars, Tcl_UtfFindFirst, Tcl_UtfFindLast, Tcl_UtfNext, Tcl_UtfPrev, Tcl_UniCharAtIndex, Tcl_UtfAtIndex, Tcl_UtfBackslash \- routines for manipulating UTF-8 strings
+Tcl_UniChar, Tcl_UniCharToUtf, Tcl_UtfToUniChar, Tcl_UtfToChar16, Tcl_UtfToWChar, Tcl_UniCharToUtfDString, Tcl_UtfToUniCharDString, Tcl_Char16ToUtfDString, Tcl_UtfToWCharDString, Tcl_UtfToChar16DString, Tcl_WCharLen, Tcl_Char16Len, Tcl_UniCharLen, Tcl_UniCharNcmp, Tcl_UniCharNcasecmp, Tcl_UniCharCaseMatch, Tcl_UtfNcmp, Tcl_UtfNcasecmp, Tcl_UtfCharComplete, Tcl_NumUtfChars, Tcl_UtfFindFirst, Tcl_UtfFindLast, Tcl_UtfNext, Tcl_UtfPrev, Tcl_UniCharAtIndex, Tcl_UtfAtIndex, Tcl_UtfBackslash \- routines for manipulating UTF-8 strings
 .SH SYNOPSIS
 .nf
 \fB#include <tcl.h>\fR
@@ -46,6 +46,12 @@ wchar_t *
 \fBTcl_UtfToWCharDString\fR(\fIsrc, length, dsPtr\fR)
 .sp
 int
+\fBTcl_Char16Len\fR(\fIuniStr\fR)
+.sp
+int
+\fBTcl_WCharLen\fR(\fIuniStr\fR)
+.sp
+int
 \fBTcl_UniCharLen\fR(\fIuniStr\fR)
 .sp
 int
@@ -198,6 +204,14 @@ representation of the UTF-8 string.  Storage for the return value
 is appended to the end of the \fBTcl_DString\fR.  The Unicode string
 is terminated with a Unicode null character.
 .PP
+\fBTcl_Char16Len\fR corresponds to \fBstrlen\fR for UTF-16
+characters.  It accepts a null-terminated Unicode string and returns
+the number of Unicode characters (not bytes) in that string.
+.PP
+\fBTcl_WCharLen\fR corresponds to \fBstrlen\fR for wchar_t
+characters.  It accepts a null-terminated Unicode string and returns
+the number of Unicode characters (not bytes) in that string.
+.PP
 \fBTcl_UniCharLen\fR corresponds to \fBstrlen\fR for Unicode
 characters.  It accepts a null-terminated Unicode string and returns
 the number of Unicode characters (not bytes) in that string.
diff --git a/doc/binary.n b/doc/binary.n
index 9ab694e..70f569b 100644
--- a/doc/binary.n
+++ b/doc/binary.n
@@ -82,6 +82,8 @@ RFC 2045 calls for base64 decoders to be non-strict.
 .
 The \fBhex\fR binary encoding converts each byte to a pair of hexadecimal
 digits that represent the byte value as a hexadecimal integer.
+When encoding, lower characters are used.
+When decoding, upper and lower characters are accepted.
 .RS
 .PP
 No options are supported during encoding. During decoding, the following
diff --git a/doc/chan.n b/doc/chan.n
index f788bbf..9589f98 100644
--- a/doc/chan.n
+++ b/doc/chan.n
@@ -1,5 +1,6 @@
 '\"
 '\" Copyright (c) 2005-2006 Donal K. Fellows
+'\" Copyright (c) 2021 Nathan Coulter
 '\"
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
@@ -8,761 +9,586 @@
 .BS
 '\" Note:  do not modify the .SH NAME line immediately below!
 .SH NAME
-chan \- Read, write and manipulate channels
+chan \- Reads, writes and manipulates channels.
 .SH SYNOPSIS
-\fBchan \fIoption\fR ?\fIarg arg ...\fR?
+\fBchan \fIoperation\fR ?\fIarg arg ...\fR?
 .BE
 .SH DESCRIPTION
 .PP
-This command provides several operations for reading from, writing to
-and otherwise manipulating open channels (such as have been created
-with the \fBopen\fR and \fBsocket\fR commands, or the default named
-channels \fBstdin\fR, \fBstdout\fR or \fBstderr\fR which correspond to
-the process's standard input, output and error streams respectively).
-\fIOption\fR indicates what to do with the channel; any unique
-abbreviation for \fIoption\fR is acceptable. Valid options are:
-.TP
-\fBchan blocked \fIchannelId\fR
-.
-This tests whether the last input operation on the channel called
-\fIchannelId\fR failed because it would have otherwise caused the
-process to block, and returns 1 if that was the case. It returns 0
-otherwise. Note that this only ever returns 1 when the channel has
-been configured to be non-blocking; all Tcl channels have blocking
-turned on by default.
-.TP
-\fBchan close \fIchannelId\fR ?\fIdirection\fR?
-.
-Close and destroy the channel called \fIchannelId\fR. Note that this
-deletes all existing file-events registered on the channel.
-If the \fIdirection\fR argument (which must be \fBread\fR or \fBwrite\fR or
-any unique abbreviation of them) is present, the channel will only be
-half-closed, so that it can go from being read-write to write-only or
-read-only respectively. If a read-only channel is closed for reading, it is
-the same as if the channel is fully closed, and respectively similar for
-write-only channels. Without the \fIdirection\fR argument, the channel is
-closed for both reading and writing (but only if those directions are
-currently open). It is an error to close a read-only channel for writing, or a
-write-only channel for reading.
+\fBchan\fR provides several operations for reading from, writing to, and
+otherwise manipulating channels, e.g. those created by \fBopen\fR and
+\fBsocket\fR, or the default channels \fBstdin\fR, \fBstdout\fR or \fBstderr\fR
+which correspond respectively to the standard input, output, and error streams
+of the process.  Any unique abbreviation for \fIoperation\fR is acceptable.
+Available operations are:
+.TP
+\fBchan blocked \fIchannelName\fR
+.
+Returns 1 when the channel is in non-blocking mode and the last input operation
+on the channel failed because it would have otherwise caused the process to
+block, and 0 otherwise.  Each Tcl channel is in blocking mode unless configured
+otherwise.
+.TP
+\fBchan close \fIchannelName\fR ?\fIdirection\fR?
+.
+Closes and destroys the named channel, deleting any existing event handlers
+established for the channel, and returns the empty string.  If \fIdirection\fR is
+given, it is
+.QW\fBread\fR
+or
+.QW\fBwrite\fR
+or any unique abbreviation of those words, and only that side of the channel is
+closed. I.e. a read-write channel may become read-only or write-only.
+Closing a read-only channel for reading, or closing a write-only channel for
+writing is the same as simply closing the channel.  It is an error to close a
+read-only channel for writing or to close a write-only channel for reading.
 .RS
 .PP
-As part of closing the channel, all buffered output is flushed to the
-channel's output device (only if the channel is ceasing to be writable), any
-buffered input is discarded (only if the channel is ceasing to be readable),
-the underlying operating system resource is closed and \fIchannelId\fR becomes
-unavailable for future use (both only if the channel is being completely
-closed).
-.PP
-If the channel is blocking and the channel is ceasing to be writable, the
-command does not return until all output is flushed.  If the channel is
-non-blocking and there is unflushed output, the channel remains open and the
-command returns immediately; output will be flushed in the background and the
-channel will be closed when all the flushing is complete.
-.PP
-If \fIchannelId\fR is a blocking channel for a command pipeline then
-\fBchan close\fR waits for the child processes to complete.
-.PP
-If the channel is shared between interpreters, then \fBchan close\fR
-makes \fIchannelId\fR unavailable in the invoking interpreter but has
-no other effect until all of the sharing interpreters have closed the
-channel. When the last interpreter in which the channel is registered
-invokes \fBchan close\fR (or \fBclose\fR), the cleanup actions
-described above occur. With half-closing, the half-close of the channel only
-applies to the current interpreter's view of the channel until all channels
-have closed it in that direction (or completely).
-See the \fBinterp\fR command for a description of channel sharing.
-.PP
-Channels are automatically fully closed when an interpreter is destroyed and
-when the process exits.  Channels are switched to blocking mode, to
-ensure that all output is correctly flushed before the process exits.
-.PP
-The command returns an empty string, and may generate an error if
-an error occurs while flushing output.  If a command in a command
-pipeline created with \fBopen\fR returns an error, \fBchan close\fR
-generates an error (similar to the \fBexec\fR command.)
-.PP
-Note that half-closes of sockets and command pipelines can have important side
-effects because they result in a shutdown() or close() of the underlying
-system resource, which can change how other processes or systems respond to
-the Tcl program.
+When a channel is closed for writing, any buffered output on the channel is
+flushed. When a channel is closed for reading, any buffered input is discarded.
+When a channel is destroyed the underlying resource is closed and the channel
+is thereafter unavailable.
+.PP
+\fBchan close\fR fully flushes any output before closing the write side of a
+channel unless it is non-blocking mode, where it returns immediately and the
+channel is flushed in the background before finally being closed.
+.PP
+\fBchan close\fR may return an error if an error occurs while flushing
+output.  If a process in a command pipeline created by \fBopen\fR returns an
+error, \fBchan close\fR generates an error in the same manner as \fBexec\fR.
+.PP
+Closing one side of a socket or command pipeline may lead to the shutdown() or
+close() of the underlying system resource, leading to a reaction from whatever
+is on the other side of the pipeline or socket.
+.PP
+If the channel for a command pipeline is in blocking mode, \fBchan close\fR
+waits for the connected processes to complete.
+.PP
+\fBchan close\fR only affects the current interpreter.  If the channel is open
+in any other interpreter, its state is unchanged there.  See \fBinterp\fR for a
+description of channel sharing.
+.PP
+When the last interpreter sharing a channel is destroyed, the channel is
+switched to blocking mode and fully flushed and then closed.
 .RE
 .TP
-\fBchan configure \fIchannelId\fR ?\fIoptionName\fR? ?\fIvalue\fR? ?\fIoptionName value\fR?...
+\fBchan configure \fIchannelName\fR ?\fIoptionName\fR? ?\fIvalue\fR? ?\fIoptionName value\fR?...
 .
-Query or set the configuration options of the channel named
-\fIchannelId\fR.
+Configures or reports the configuration of \fIchannelName\fR.
 .RS
 .PP
-If no \fIoptionName\fR or \fIvalue\fR arguments are supplied, the
-command returns a list containing alternating option names and values
-for the channel.  If \fIoptionName\fR is supplied but no \fIvalue\fR
-then the command returns the current value of the given option.  If
-one or more pairs of \fIoptionName\fR and \fIvalue\fR are supplied,
-the command sets each of the named options to the corresponding
-\fIvalue\fR; in this case the return value is an empty string.
-.PP
-The options described below are supported for all channels. In
-addition, each channel type may add options that only it supports. See
-the manual entry for the command that creates each type of channel
-for the options supported by that specific type of channel. For
-example, see the manual entry for the \fBsocket\fR command for additional
-options for sockets, and the \fBopen\fR command for additional options for
-serial devices.
+If no \fIoptionName\fR or \fIvalue\fR arguments are given,
+\fBchan configure\fR returns a dictionary of option names and
+values for the channel.  If \fIoptionName\fR is supplied without a \fIvalue\fR,
+\fBchan configure\fR returns the current value of the named option.  If one or
+more pairs of \fIoptionName\fR and \fIvalue\fR are supplied,
+\fBchan configure\fR sets each of the named options to the corresponding
+\fIvalue\fR and returns the empty string.
+.PP
+The options described below are supported for all channels. Each type of
+channel may provide additional options. Those options are described in the
+relevant documentation. For example, additional options are documented for
+\fBsocket\fR, and also for serial devices at \fBopen\fR.
 .TP
 \fB\-blocking\fR \fIboolean\fR
 .
-The \fB\-blocking\fR option determines whether I/O operations on the
-channel can cause the process to block indefinitely.  The value of the
-option must be a proper boolean value.  Channels are normally in
-blocking mode; if a channel is placed into non-blocking mode it will
-affect the operation of the \fBchan gets\fR, \fBchan read\fR, \fBchan
-puts\fR, \fBchan flush\fR, and \fBchan close\fR commands; see the
-documentation for those commands for details.  For non-blocking mode to
-work correctly, the application must be using the Tcl event loop
-(e.g. by calling \fBTcl_DoOneEvent\fR or invoking the \fBvwait\fR
-command).
+If \fB\-blocking\fR is set to \fBtrue\fR, which is the default, reading from or
+writing to the channel may cause the process to block indefinitely.  Otherwise,
+operations such as \fBchan gets\fR, \fBchan read\fR, \fBchan puts\fR, \fBchan
+flush\fR, and \fBchan close\fR take care not to block.  Non-blocking mode in
+generally requires that the event loop is entered, e.g. by calling
+\fBTcl_DoOneEvent\fR or \fBvwait\fR or by using Tk, to give Tcl a chance to
+process events on the channel.
 .TP
 \fB\-buffering\fR \fInewValue\fR
 .
-If \fInewValue\fR is \fBfull\fR then the I/O system will buffer output
-until its internal buffer is full or until the \fBchan flush\fR
-command is invoked. If \fInewValue\fR is \fBline\fR, then the I/O
-system will automatically flush output for the channel whenever a
-newline character is output. If \fInewValue\fR is \fBnone\fR, the I/O
-system will flush automatically after every output operation.  The
-default is for \fB\-buffering\fR to be set to \fBfull\fR except for
-channels that connect to terminal-like devices; for these channels the
-initial setting is \fBline\fR.  Additionally, \fBstdin\fR and
-\fBstdout\fR are initially set to \fBline\fR, and \fBstderr\fR is set
-to \fBnone\fR.
+If \fInewValue\fR is \fBfull\fR, which is the default, output is buffered
+until the internal buffer is full or until \fBchan flush\fR is called. If
+\fInewValue\fR is \fBline\fR, output is flushed each time a end-of-line
+character is written. If \fInewValue\fR is \fBnone\fR, output is flushed after
+every output operation.  For \fBstdin\fR, \fBstdout\fR, and channels that
+connect to terminal-like devices, the default value is \fBline\fR.  For
+\fBstderr\fR the default value is \fBnone\fR.
 .TP
 \fB\-buffersize\fR \fInewSize\fR
 .
-\fINewvalue\fR must be an integer; its value is used to set the size
-of buffers, in bytes, subsequently allocated for this channel to store
-input or output. \fINewvalue\fR must be a number of no more than one
-million, allowing buffers of up to one million bytes in size.
-.TP
-\fB\-encoding\fR \fIname\fR
-.
-This option is used to specify the encoding of the channel as one of
-the named encodings returned by \fBencoding names\fR or the special
-value \fBbinary\fR, so that the data can be converted to and from
-Unicode for use in Tcl.  For instance, in order for Tcl to read
-characters from a Japanese file in \fBshiftjis\fR and properly process
-and display the contents, the encoding would be set to \fBshiftjis\fR.
-Thereafter, when reading from the channel, the bytes in the Japanese
-file would be converted to Unicode as they are read.  Writing is also
-supported \- as Tcl strings are written to the channel they will
-automatically be converted to the specified encoding on output.
+\fInewSize\fR, an integer no greater than one million, is the size in bytes of
+any input or output buffers subsequently allocated for this channel.
+.TP
+\fB\-encoding\fR ?\fIname\fR?
+.
+Sets the encoding of the channel.  \fIname\fR is either one of the names
+returned by \fBencoding names\fR, or
+.QW \fBbinary\fR
+\&. Input is converted from the encoding into Unicode, and output is converted
+from Unicode to the encoding.
 .RS
 .PP
-If a file contains pure binary data (for instance, a JPEG image), the
-encoding for the channel should be configured to be \fBbinary\fR.  Tcl
-will then assign no interpretation to the data in the file and simply
-read or write raw bytes.  The Tcl \fBbinary\fR command can be used to
-manipulate this byte-oriented data.  It is usually better to set the
-\fB\-translation\fR option to \fBbinary\fR when you want to transfer
-binary data, as this turns off the other automatic interpretations of
-the bytes in the stream as well.
-.PP
-The default encoding for newly opened channels is the same platform-
-and locale-dependent system encoding used for interfacing with the
-operating system, as returned by \fBencoding system\fR.
+\fBbinary\fR is an alias for \fBiso8859-1\fR: Each byte read from the
+channel becomes the Unicode character having the same value as that byte, and
+each character written to the channel becomes a single byte in the output,
+allowing Tcl to work seamlessly with binary data as long as each "character" in
+the data remains in the range of 0 to 255 so that there is no distinction between
+binary data and text.  For example, A JPEG image can be read from a
+\fBbinary\fR channel, manipulated, and then written back to a \fBbinary\fR
+channel.
+
+For working with binary data \fB\-translation binary\fR is usually used
+instead, as it sets the encoding to \fBbinary\fR and also disables other
+translations on the channel.
+.PP
+The encoding of a new channel is the value of \fBencoding system\fR,
+which returns the platform- and locale-dependent system encoding used to
+interface with the operating system,
 .RE
 .TP
 \fB\-eofchar\fR \fIchar\fR
 .TP
 \fB\-eofchar\fR \fB{\fIinChar outChar\fB}\fR
 .
-This option supports DOS file systems that use Control-z (\ex1A) as an
-end of file marker.  If \fIchar\fR is not an empty string, then this
-character signals end-of-file when it is encountered during input.
-For output, the end-of-file character is output when the channel is
-closed.  If \fIchar\fR is the empty string, then there is no special
-end of file character marker.  For read-write channels, a two-element
-list specifies the end of file marker for input and output,
-respectively.  As a convenience, when setting the end-of-file
-character for a read-write channel you can specify a single value that
-will apply to both reading and writing.  When querying the end-of-file
-character of a read-write channel, a two-element list will always be
-returned.  The default value for \fB\-eofchar\fR is the empty string
-in all cases except for files under Windows.  In that case the
-\fB\-eofchar\fR is Control-z (\ex1A) for reading and the empty string
-for writing.
-The acceptable range for \fB\-eofchar\fR values is \ex01 - \ex7f;
-attempting to set \fB\-eofchar\fR to a value outside of this range will
-generate an error.
-.TP
-\fB\-translation\fR \fImode\fR
-.TP
-\fB\-translation\fR \fB{\fIinMode outMode\fB}\fR
-.
-In Tcl scripts the end of a line is always represented using a single
-newline character (\en).  However, in actual files and devices the end
-of a line may be represented differently on different platforms, or
-even for different devices on the same platform.  For example, under
-UNIX newlines are used in files, whereas carriage-return-linefeed
-sequences are normally used in network connections.  On input (i.e.,
-with \fBchan gets\fR and \fBchan read\fR) the Tcl I/O system
-automatically translates the external end-of-line representation into
-newline characters.  Upon output (i.e., with \fBchan puts\fR), the I/O
-system translates newlines to the external end-of-line representation.
-The default translation mode, \fBauto\fR, handles all the common cases
-automatically, but the \fB\-translation\fR option provides explicit
-control over the end of line translations.
+\fIchar\fR signals the end of the data when it is encountered in the input.
+For output, the character is added when the channel is closed.  If \fIchar\fR
+is the empty string, there is no special character that marks the end of the
+data.  For read-write channels, one end-of-file character for input and another
+for output may be given.  When only one end-of-file character is given it is
+applied to both input and output.  For a read-write channel two values are
+returned even if they are are identical.
+
+The default value is the empty string, except that under Windows the default
+value for reading is Control-z (\ex1A).  The acceptable range is \ex01 -
+\ex7f.  A value outside this range results in an error.
+.TP
+\fB\-translation\fR \fItranslation\fR
+.TP
+\fB\-translation\fR \fB{\fIinTranslation outTranslation\fB}\fR
+.
+In Tcl a single line feed (\en) represents the end of a line.  However,
+at the destination the end of a line may be represented differently on
+different platforms, or even for different devices on the same platform.  For
+example, under UNIX line feed is used in files and a
+carriage-return-linefeed sequence is normally used in network connections.
+Therefore, on input, e.g. with \fBchan gets\fR and \fBchan read\fR, each
+external end-of-line character is translated into a line feed.  On
+output, e.g. with \fBchan puts\fR, each line feed is translated to the external
+end-of-line character.  The default translation, \fBauto\fR, handles all the common
+cases, and \fB\-translation\fR provides explicit control over the end-of-line
+character.
 .RS
 .PP
-The value associated with \fB\-translation\fR is a single item for
-read-only and write-only channels.  The value is a two-element list for
-read-write channels; the read translation mode is the first element of
-the list, and the write translation mode is the second element.  As a
-convenience, when setting the translation mode for a read-write channel
-you can specify a single value that will apply to both reading and
-writing.  When querying the translation mode of a read-write channel, a
-two-element list will always be returned.  The following values are
-currently supported:
+Returns the input translation for a read-only channel, the output translation
+for a write-only channel, and both the input translation and the the output
+translation for a  read-write channel.  When two translations are given, they
+are the input and output translation, respectively.  When only one translation
+is given for a read-write channel, it is the translation for both input and
+output.  The following values are currently supported:
 .TP
 \fBauto\fR
 .
-As the input translation mode, \fBauto\fR treats any of newline
-(\fBlf\fR), carriage return (\fBcr\fR), or carriage return followed by
-a newline (\fBcrlf\fR) as the end of line representation.  The end of
-line representation can even change from line-to-line, and all cases
-are translated to a newline.  As the output translation mode,
-\fBauto\fR chooses a platform specific representation; for sockets on
-all platforms Tcl chooses \fBcrlf\fR, for all Unix flavors, it chooses
-\fBlf\fR, and for the various flavors of Windows it chooses
-\fBcrlf\fR.  The default setting for \fB\-translation\fR is \fBauto\fR
-for both input and output.
+The default.  For input each occurrence of a line feed (\fBlf\fR), carriage
+return (\fBcr\fR), or carriage return followed by a line feed (\fBcrlf\fR) is
+translated into a line feed.  For output, each line feed is translated into a
+platform-specific representation:  For all Unix variants it is \fBlf\fR, and
+for all Windows variants it is \fBcrlf\fR, except that for sockets on all
+platforms it is \fBcrlf\fR for both input and output.
 .TP
 \fBbinary\fR
 .
-No end-of-line translations are performed.  This is nearly identical
-to \fBlf\fR mode, except that in addition \fBbinary\fR mode also sets
-the end-of-file character to the empty string (which disables it) and
-sets the encoding to \fBbinary\fR (which disables encoding filtering).
-See the description of \fB\-eofchar\fR and \fB\-encoding\fR for more
-information.
+Like \fBlf\fR, no end-of-line translation is performed, but in addition,
+\fB\-eofchar\fR is set to the empty string to disable it, and \fB\-encoding\fR
+is set to \fBbinary\fR.  With this one setting, a channel is fully configured
+for binary input and output.
 .TP
 \fBcr\fR
 .
-The end of a line in the underlying file or device is represented by a
-single carriage return character.  As the input translation mode,
-\fBcr\fR mode converts carriage returns to newline characters.  As the
-output translation mode, \fBcr\fR mode translates newline characters
-to carriage returns.
+The end of a line is represented in the external data by a single carriage
+return character.  For input, each carriage return is translated to a line
+feed, and for output each line feed character is translated to a carriage
+return.
 .TP
 \fBcrlf\fR
 .
-The end of a line in the underlying file or device is represented by a
-carriage return character followed by a linefeed character.  As the
-input translation mode, \fBcrlf\fR mode converts
-carriage-return-linefeed sequences to newline characters.  As the
-output translation mode, \fBcrlf\fR mode translates newline characters
-to carriage-return-linefeed sequences.  This mode is typically used on
-Windows platforms and for network connections.
+The end of a line is represented in the external data by a carriage return
+character followed by a line feed.  For input, each carriage-return-linefeed
+sequence is translated to a line feed.  For output, each line feed is
+translated to a carriage-return-linefeed sequence.  This translation is
+typically used for network connections, and also on Windows systems.
 .TP
 \fBlf\fR
 .
-The end of a line in the underlying file or device is represented by a
-single newline (linefeed) character.  In this mode no translations
-occur during either input or output.  This mode is typically used on
-UNIX platforms.
+The end of a line in the external data is represented by a line feed so no
+translations occur during either input or output.  This translation is
+typically used on UNIX platforms,
 .RE
 .RE
 .TP
 \fBchan copy \fIinputChan outputChan\fR ?\fB\-size \fIsize\fR? ?\fB\-command \fIcallback\fR?
 .
-Copy data from the channel \fIinputChan\fR, which must have been
-opened for reading, to the channel \fIoutputChan\fR, which must have
-been opened for writing. The \fBchan copy\fR command leverages the
-buffering in the Tcl I/O system to avoid extra copies and to avoid
-buffering too much data in main memory when copying large files to
-slow destinations like network sockets.
+Copies data from \fIinputChan\fR to \fIoutputChan\fR, leveraging internal
+buffers to avoid extra copies and to avoid buffering too much data in main
+memory when copying large files to slow destinations like network sockets.
 .RS
 .PP
-The \fBchan copy\fR command transfers data from \fIinputChan\fR until
-end of file or \fIsize\fR bytes or characters have been transferred;
-\fIsize\fR is in bytes if the two channels are using the same encoding,
-and is in characters otherwise.  If no \fB\-size\fR argument is given,
-then the copy goes until end of file. All the data read from
-\fIinputChan\fR is copied to \fIoutputChan\fR.  Without the
-\fB\-command\fR option, \fBchan copy\fR blocks until the copy is
-complete and returns the number of bytes or characters (using the same
-rules as for the \fB\-size\fR option) written to \fIoutputChan\fR.
-.PP
-The \fB\-command\fR argument makes \fBchan copy\fR work in the
-background.  In this case it returns immediately and the
-\fIcallback\fR is invoked later when the copy completes.  The
-\fIcallback\fR is called with one or two additional arguments that
-indicates how many bytes were written to \fIoutputChan\fR.  If an
-error occurred during the background copy, the second argument is the
-error string associated with the error.  With a background copy, it is
-not necessary to put \fIinputChan\fR or \fIoutputChan\fR into
-non-blocking mode; the \fBchan copy\fR command takes care of that
-automatically.  However, it is necessary to enter the event loop by
-using the \fBvwait\fR command or by using Tk.
-.PP
-You are not allowed to do other I/O operations with \fIinputChan\fR or
-\fIoutputChan\fR during a background \fBchan copy\fR.  If either
-\fIinputChan\fR or \fIoutputChan\fR get closed while the copy is in
-progress, the current copy is stopped and the command callback is
-\fInot\fR made.  If \fIinputChan\fR is closed, then all data already
-queued for \fIoutputChan\fR is written out.
-.PP
-Note that \fIinputChan\fR can become readable during a background
-copy.  You should turn off any \fBchan event\fR or \fBfileevent\fR
-handlers during a background copy so those handlers do not interfere
-with the copy.  Any I/O attempted by a \fBchan event\fR or
-\fBfileevent\fR handler will get a
-.QW "channel busy"
-error.
-.PP
-\fBChan copy\fR translates end-of-line sequences in \fIinputChan\fR
-and \fIoutputChan\fR according to the \fB\-translation\fR option for
-these channels (see \fBchan configure\fR above).  The translations
-mean that the number of bytes read from \fIinputChan\fR can be
-different than the number of bytes written to \fIoutputChan\fR.  Only
-the number of bytes written to \fIoutputChan\fR is reported, either as
-the return value of a synchronous \fBchan copy\fR or as the argument
-to the callback for an asynchronous \fBchan copy\fR.
-.PP
-\fBChan copy\fR obeys the encodings and character translations
-configured for the channels. This means that the incoming characters
-are converted internally first UTF-8 and then into the encoding of the
-channel \fBchan copy\fR writes to (see \fBchan configure\fR above for
-details on the \fB\-encoding\fR and \fB\-translation\fR options). No
-conversion is done if both channels are set to encoding \fBbinary\fR
-and have matching translations. If only the output channel is set to
-encoding \fBbinary\fR the system will write the internal UTF-8
-representation of the incoming characters. If only the input channel
-is set to encoding \fBbinary\fR the system will assume that the
-incoming bytes are valid UTF-8 characters and convert them according
-to the output encoding. The behaviour of the system for bytes which
-are not valid UTF-8 characters is undefined in this case.
+If \fB\-size\fR is given, the size is in bytes if the two channels have the
+same encoding and in characters otherwise, and only that amount is copied.
+Otherwise, all data until the end of the file is copied.
+
+\fBchan copy\fR blocks until the copy is complete and returns the number of
+bytes or characters written to \fIoutputChan\fR.
+.PP
+If \fB\-command\fR is given, \fBchan copy\fR returns immediately, the copy is
+carried out in the background, and then \fIcallback\fR is called with the
+number of bytes written to \fIoutputChan\fR as its first argument, and the
+error message for any error that occurred as its second argument.
+\fIinputChan\fR and \fIoutputChan\fR are automatically configured for
+non-blocking mode if needed.  Background copying only works correctly if the
+event loop is active, e.g. via \fBvwait\fR or Tk.
+.PP
+During a background copy no other read or write operation may be performed on
+\fIinputChan\fR or \fIoutputChan\fR.  If either \fIinputChan\fR or
+\fIoutputChan\fR is closed while the copy is in progress copying ceases and
+\fBno\fR callback is made.  If \fIinputChan\fR is closed all data already queued
+is written to \fIoutputChan\fR.
+.PP
+The should be no event handler established for \fIinputChan\fR  because it may
+become readable during a background copy.  An attempt to read or write
+from within an event handler results result in the error,  "channel busy".
+.PP
+Due to end-of-line translation the number of bytes read from \fIinputChan\fR
+may be different than the number of bytes written to \fIoutputChan\fR.  Only
+the number of bytes written to \fIoutputChan\fR is reported.
+.PP
+\fBChan copy\fR reads the data according to the \fB\-encoding\fR,
+\fB\-translation\fR, and \fB\-eofchar\fR of the source and writes to the
+destination according to the configuration for that channel.  If the encoding
+and translation of both channels is \fBbinary\fR and the \fB\-eofchar\fR of
+both channels is the empty string, an identical copy is made.  If only the
+encoding of the destination is \fBbinary\fR, Tcl's internal modified UTF-8
+representation of the characters read from the source is written to the
+destination. If only the encoding of the source is \fBbinary\fR, each byte read
+becomes one Unicode character in the range of 0 to 255, and that character is
+subject to the encoding and translation of the destination as it is written.
 .RE
 .TP
 \fBchan create \fImode cmdPrefix\fR
 .
-This subcommand creates a new script level channel using the command
-prefix \fIcmdPrefix\fR as its handler. Any such channel is called a
-\fBreflected\fR channel. The specified command prefix, \fBcmdPrefix\fR,
-must be a non-empty list, and should provide the API described in the
-\fBrefchan\fR manual page. The handle of the new channel is
-returned as the result of the \fBchan create\fR command, and the
-channel is open. Use either \fBclose\fR or \fBchan close\fR to remove
-the channel.
+Creates a new channel, called a \fBreflected\fR channel, with \fIcmdPrefix\fR
+as its handler, and returns the name of the channel.  \fBcmdPrefix\fR is the
+first words of a command that provides the interface for a \fBrefchan\fR.
 .RS
 .PP
-The argument \fImode\fR specifies if the new channel is opened for
-reading, writing, or both. It has to be a list containing any of the
-strings
+\fBImode\fR is a list of one or more of the strings
 .QW \fBread\fR
 or
-.QW \fBwrite\fR .
-The list must have at least one
-element, as a channel you can neither write to nor read from makes no
-sense. The handler command for the new channel must support the chosen
-mode, or an error is thrown.
-.PP
-The command prefix is executed in the global namespace, at the top of
-call stack, following the appending of arguments as described in the
-\fBrefchan\fR manual page. Command resolution happens at the
-time of the call. Renaming the command, or destroying it means that
-the next call of a handler method may fail, causing the channel
-command invoking the handler to fail as well. Depending on the
-subcommand being invoked, the error message may not be able to explain
-the reason for that failure.
-.PP
-Every channel created with this subcommand knows which interpreter it
-was created in, and only ever executes its handler command in that
-interpreter, even if the channel was shared with and/or was moved into
-a different interpreter. Each reflected channel also knows the thread
-it was created in, and executes its handler command only in that
-thread, even if the channel was moved into a different thread. To this
-end all invocations of the handler are forwarded to the original
-thread by posting special events to it. This means that the original
-thread (i.e. the thread that executed the \fBchan create\fR command)
-must have an active event loop, i.e. it must be able to process such
-events. Otherwise the thread sending them will \fIblock
-indefinitely\fR. Deadlock may occur.
-.PP
-Note that this permits the creation of a channel whose two endpoints
-live in two different threads, providing a stream-oriented bridge
-between these threads. In other words, we can provide a way for
-regular stream communication between threads instead of having to send
-commands.
-.PP
-When a thread or interpreter is deleted, all channels created with
-this subcommand and using this thread/interpreter as their computing
-base are deleted as well, in all interpreters they have been shared
-with or moved into, and in whatever thread they have been transferred
-to. While this pulls the rug out under the other thread(s) and/or
-interpreter(s), this cannot be avoided. Trying to use such a channel
-will cause the generation of a regular error about unknown channel
-handles.
-.PP
-This subcommand is \fBsafe\fR and made accessible to safe
-interpreters.  While it arranges for the execution of arbitrary Tcl
-code the system also makes sure that the code is always executed
-within the safe interpreter.
+.QW \fBwrite\fR
+, indicating whether the channel is a read channel, a write channel, or both.
+It is an error if the handler does not support the chosen mode.
+.PP
+The handler is called as needed from the global namespace at the top level, and
+command resolution happens there at the time of the call.  If the handler is
+renamed or deleted any subsequent attempt to call it is an error, which may
+not be able to describe the failure.
+.PP
+The handler is always called in the interpreter and thread it was created in,
+even if the channel was shared with or moved into a different interpreter in a
+different thread.  This is achieved through event dispatch, so if the event
+loop is not entered, e.g. by calling \fBTcl_DoOneEvent\fR or \fBvwait\fR or
+using Tk, the thread performing the channel operation \fIblocks
+indefinitely\fR, resulting in deadlock.
+.PP
+One side of a channel may be in one thread while the other side is in a
+different thread, providing a stream-oriented bridge between the threads. This
+provides a method for regular stream communication between threads as an
+alternative to sending commands.
+.PP
+When the interpreter the handler is in is deleted each channel associated with
+the handler is deleted as well, regardless of which interpreter or thread it
+is currently in or shared with.
+.PP
+\fBchan create\fR is \fBsafe\fR and is accessible to safe interpreters.  The
+handler is always called in the safe interpreter it was created in.
 .RE
 .TP
-\fBchan eof \fIchannelId\fR
-.
-Test whether the last input operation on the channel called
-\fIchannelId\fR failed because the end of the data stream was reached,
-returning 1 if end-of-file was reached, and 0 otherwise.
-.TP
-\fBchan event \fIchannelId event\fR ?\fIscript\fR?
-.
-Arrange for the Tcl script \fIscript\fR to be installed as a \fIfile
-event handler\fR to be called whenever the channel called
-\fIchannelId\fR enters the state described by \fIevent\fR (which must
-be either \fBreadable\fR or \fBwritable\fR); only one such handler may
-be installed per event per channel at a time.  If \fIscript\fR is the
-empty string, the current handler is deleted (this also happens if the
-channel is closed or the interpreter deleted).  If \fIscript\fR is
-omitted, the currently installed script is returned (or an empty
-string if no such handler is installed).  The callback is only
-performed if the event loop is being serviced (e.g. via \fBvwait\fR or
-\fBupdate\fR).
-.RS
-.PP
-A file event handler is a binding between a channel and a script, such
-that the script is evaluated whenever the channel becomes readable or
-writable.  File event handlers are most commonly used to allow data to
-be received from another process on an event-driven basis, so that the
-receiver can continue to interact with the user or with other channels
-while waiting for the data to arrive.  If an application invokes
-\fBchan gets\fR or \fBchan read\fR on a blocking channel when there is
-no input data available, the process will block; until the input data
-arrives, it will not be able to service other events, so it will
-appear to the user to
-.QW "freeze up" .
-With \fBchan event\fR, the
-process can tell when data is present and only invoke \fBchan gets\fR
-or \fBchan read\fR when they will not block.
-.PP
-A channel is considered to be readable if there is unread data
-available on the underlying device.  A channel is also considered to
-be readable if there is unread data in an input buffer, except in the
-special case where the most recent attempt to read from the channel
-was a \fBchan gets\fR call that could not find a complete line in the
-input buffer.  This feature allows a file to be read a line at a time
-in non-blocking mode using events.  A channel is also considered to be
-readable if an end of file or error condition is present on the
-underlying file or device.  It is important for \fIscript\fR to check
-for these conditions and handle them appropriately; for example, if
-there is no special check for end of file, an infinite loop may occur
-where \fIscript\fR reads no data, returns, and is immediately invoked
-again.
-.PP
-A channel is considered to be writable if at least one byte of data
-can be written to the underlying file or device without blocking, or
-if an error condition is present on the underlying file or device.
-Note that client sockets opened in asynchronous mode become writable
-when they become connected or if the connection fails.
-.PP
-Event-driven I/O works best for channels that have been placed into
-non-blocking mode with the \fBchan configure\fR command.  In blocking
-mode, a \fBchan puts\fR command may block if you give it more data
-than the underlying file or device can accept, and a \fBchan gets\fR
-or \fBchan read\fR command will block if you attempt to read more data
-than is ready; no events will be processed while the commands block.
-In non-blocking mode \fBchan puts\fR, \fBchan read\fR, and \fBchan
-gets\fR never block.
-.PP
-The script for a file event is executed at global level (outside the
-context of any Tcl procedure) in the interpreter in which the \fBchan
-event\fR command was invoked.  If an error occurs while executing the
-script then the command registered with \fBinterp bgerror\fR is used
-to report the error.  In addition, the file event handler is deleted
-if it ever returns an error; this is done in order to prevent infinite
-loops due to buggy handlers.
-.RE
+\fBchan eof \fIchannelName\fR
+.
+Returns 1 if the last read on the channel failed because the end of the data
+was already reached, and 0 otherwise.
 .TP
-\fBchan flush \fIchannelId\fR
+\fBchan event \fIchannelName event\fR ?\fIscript\fR?
 .
-Ensures that all pending output for the channel called \fIchannelId\fR
-is written.
+Arranges for the given script, called a \fBchannel event hndler\fR, to be
+called whenever the given event, one of
+.QW \fBreadable\fR
+or
+.QW \fBwritable\fR
+occurs on the given channel, replacing any script that was previously set.  If
+\fIscript\fR is the empty string the current handler is deleted.  It is also
+deleted when the channel is closed.  If \fIscript\fR is omitted, either the
+existing script or the empty string is returned.  The event loop must be
+entered, e.g. via \fBvwait\fR or \fBupdate\fR, or by using Tk, for handlers to
+be evaluated.
+
 .RS
 .PP
-If the channel is in blocking mode the command does not return until
-all the buffered output has been flushed to the channel. If the
-channel is in non-blocking mode, the command may return before all
-buffered output has been flushed; the remainder will be flushed in the
-background as fast as the underlying file or device is able to absorb
-it.
+\fIscript\fR is evaluated at the global level in the interpreter it was
+established in.  Any resulting error is handled in the background, i.e. via
+\fBinterp bgerror\fR.  In order to prevent an endless loop due to a buggy
+handler, the handler is deleted if \fIscript\fR returns an error so that it is
+not evaluated again.
+
+.PP
+Without an event handler, \fBchan gets\fR or \fBchan read\fR on a channel in
+blocking mode may block until data becomes available, become during which the
+thread is unable to perform other work or respond to events on other channels.
+This could cause the application to appear to
+.QW "freeze up"
+\&.
+Channel event handlers allow events on the channel to direct channel handling
+so that the reader or writer can continue to perform other processing while
+waiting for a channel to become available and then handle channel operations
+when the channel is ready for the operation.
+.PP
+A
+.QW readable
+event occurs when there is data that can be read from the channel and also when
+there is an error on the channel.  The handler must check for these conditions
+and handle them appropriately.  For example, a handler that does not check
+whether the end of the data has been reached may be repeatedly evaluated in a
+busy loop until the channel is closed.
+.PP
+A
+.QW writable
+event occurs when at least one byte of data can be written, or if there is an
+error on the channel.  A client socket opened in non-blocking mode becomes
+writable when it becomes connected or if the connection fails.
+.PP
+Event-driven channel handling works best for channels in non-blocking mode.  A
+channel in blocking mode blocks when \fBchan puts\fR writes more data than the
+channel can accept at the moment, and when \fBchan gets\fR or \fBchan read\fR
+requests more data than is currently available.  When a channel blocks, the
+thread can not do any other processing or service any other events.  A channel
+in non-blocking mode allows a thread to carry on with other work and get back
+to the channel at the right time.
 .RE
 .TP
-\fBchan gets \fIchannelId\fR ?\fIvarName\fR?
-.
-Reads the next line from the channel called \fIchannelId\fR. If
-\fIvarName\fR is not specified, the result of the command will be the
-line that has been read (without a trailing newline character) or an
-empty string upon end-of-file or, in non-blocking mode, if the data
-available is exhausted. If \fIvarName\fR is specified, the line that
-has been read will be written to the variable called \fIvarName\fR and
-result will be the number of characters that have been read or -1 if
-end-of-file was reached or, in non-blocking mode, if the data
-available is exhausted.
+\fBchan flush \fIchannelName\fR
+.
+For a channel in blocking mode, flushes all buffered output to the destination,
+and then returns.  For a channel in non-blocking mode, returns immediately
+while all buffered output is flushed in the background as soon as possible.
+.TP
+\fBchan gets \fIchannelName\fR ?\fIvarName\fR?
+.
+Returns the next line from the channel, removing the trailing line feed, or if
+\fIvarName\fR is given, assigns the line to that variable and returns the
+number of characters read.
+the line that was read, removing the trailing line feed, or returns the
+empty string if there is no data to return and the end of the file has been
+reached, or in non-blocking mode, if no complete line is currently available.
+If \fIvarName\fR is given, assigns the line that was read to variable named
+\fIvarName\fR  and returns the number of characters that were read, or -1 if
+there no data available and the end of the channel was reached or the channel
+is in non-blocking mode.
 .RS
 .PP
-If an end-of-file occurs while part way through reading a line, the
-partial line will be returned (or written into \fIvarName\fR). When
-\fIvarName\fR is not specified, the end-of-file case can be
-distinguished from an empty line using the \fBchan eof\fR command, and
-the partial-line-but-non-blocking case can be distinguished with the
-\fBchan blocked\fR command.
+If the end of the channel is reached the data read so far is returned or
+assigned to \fIvarName\fR. When \fIvarName\fR is not given, \fBchan eof\fR may
+indicate that the empty string means that the end of the data has been reached,
+and \fBchan blocked\fR may indicate that that the empty string means there
+isn't currently enough data do return the next line.
 .RE
 .TP
 \fBchan names\fR ?\fIpattern\fR?
 .
-Produces a list of all channel names. If \fIpattern\fR is specified,
-only those channel names that match it (according to the rules of
-\fBstring match\fR) will be returned.
+Returns a list of all channel names, or if \fIpattern\fR is given, only those
+names that match according to the rules of \fBstring match\fR.
 .TP
-\fBchan pending \fImode channelId\fR
+\fBchan pending \fImode channelName\fR
 .
-Depending on whether \fImode\fR is \fBinput\fR or \fBoutput\fR,
-returns the number of
-bytes of input or output (respectively) currently buffered
-internally for \fIchannelId\fR (especially useful in a readable event
-callback to impose application-specific limits on input line lengths to avoid
-a potential denial-of-service attack where a hostile user crafts
-an extremely long line that exceeds the available memory to buffer it).
-Returns -1 if the channel was not opened for the mode in question.
+Returns the number of bytes of input
+when \fImode\fR is
+.QW\fBinput\fR
+, or output when \fImode\fR is
+.QW\fBoutput\fR
+, that are currently internally buffered for the channel.  Useful in a readable
+event callback to impose limits on input line length to avoid a potential
+denial-of-service attack where an extremely long line exceeds the available
+memory to buffer it.  Returns -1 if the channel was not opened for the mode in
+question.
 .TP
 \fBchan pipe\fR
-Creates a standalone pipe whose read- and write-side channels are
-returned as a 2-element list, the first element being the read side and
-the second the write side. Can be useful e.g. to redirect
-separately \fBstderr\fR and \fBstdout\fR from a subprocess. To do
-this, spawn with "2>@" or
-">@" redirection operators onto the write side of a pipe, and then
-immediately close it in the parent. This is necessary to get an EOF on
-the read side once the child has exited or otherwise closed its output.
+Creates a pipe, i.e. a readable channel and a writable channel, and returns the
+names of the readable channel and the writable channel.  Data written to the
+writable channel can be read from the readable channel.  Because the pipe is a
+real system-level pipe, it can be connected to other processes using
+redirection.  For example, to redirect \fBstderr\fR from a subprocess into one
+channel, and \fBstdout\fR into another, \fBexec\fR with "2>@" and ">@", each
+onto the writable side of a pipe, closing the writable side immediately
+thereafter so that EOF is signaled on the read side once the subprocess has
+closed its output, typically on exit.
 .RS
 .PP
-Note that the pipe buffering semantics can vary at the operating system level
-substantially; it is not safe to assume that a write performed on the output
-side of the pipe will appear instantly to the input side. This is a
-fundamental difference and Tcl cannot conceal it. The overall stream semantics
-\fIare\fR compatible, so blocking reads and writes will not see most of the
-differences, but the details of what exactly gets written when are not. This
-is most likely to show up when using pipelines for testing; care should be
-taken to ensure that deadlocks do not occur and that potential short reads are
-allowed for.
+Due to buffering, data written to one side of a pipe might not immediately
+become available on the other side.  Tcl's own buffers can be configured via
+\fBchan configure -buffering\fR, but overall behaviour still depends on
+operating system buffers outside of Tcl's control. Once the write side of the
+channel is closed, any data remaining in the buffers is flushed through to the
+read side.  It may be useful to arrange for the connected process to flush at
+some point after writing to the channel or to have it use some system-provided
+mechanism to configure buffering.  When two pipes are connected to the same
+process, one to send data to the process, and one to read data from the
+process, a deadlock may occur if the channels are in blocking mode:  If
+reading, the channel may block waiting for data that can never come because
+buffers are only flushed on subsequent writes, and if writing, the channel may
+block while waiting for the buffers to become free, which can never happen
+because the reader can not read while the writer is blocking.  To avoid this
+issue, either put the channels into non-blocking mode and use event handlers,
+or place the read channel and the write channel in separate interpreters in
+separate threads.
 .RE
 .TP
-\fBchan pop \fIchannelId\fR
-Removes the topmost transformation from the channel \fIchannelId\fR, if there
-is any. If there are no transformations added to \fIchannelId\fR, this is
-equivalent to \fBchan close\fR of that channel. The result is normally the
-empty string, but can be an error in some situations (i.e. where the
-underlying system stream is closed and that results in an error).
-.TP
-\fBchan postevent \fIchannelId eventSpec\fR
-.
-This subcommand is used by command handlers specified with \fBchan
-create\fR. It notifies the channel represented by the handle
-\fIchannelId\fR that the event(s) listed in the \fIeventSpec\fR have
-occurred. The argument has to be a list containing any of the strings
-\fBread\fR and \fBwrite\fR. The list must contain at least one
-element as it does not make sense to invoke the command if there are
-no events to post.
+\fBchan pop \fIchannelName\fR
+Removes the topmost transformation handler from the channel if there is one,
+and closes the channel otherwise. The result is normally the empty string, but
+may be an error in some situations, e.g. when closing the underlying resource
+results in an error.
+.TP
+\fBchan postevent \fIchannelName eventSpec\fR
+.
+For use by handlers established with \fBchan create\fR.  Notifies Tcl that
+that one or more event(s) listed in \fIeventSpec\fR, each of which is either
+.QW\fBread\fR
+or
+.QW\fBwrite\fR.
+, have occurred.
 .RS
 .PP
-Note that this subcommand can only be used with channel handles that
-were created/opened by \fBchan create\fR. All other channels will
-cause this subcommand to report an error.
-.PP
-As only the Tcl level of a channel, i.e. its command handler, should
-post events to it we also restrict the usage of this command to the
-interpreter that created the channel. In other words, posting events
-to a reflected channel from an interpreter that does not contain it's
-implementation is not allowed. Attempting to post an event from any
-other interpreter will cause this subcommand to report an error.
-.PP
-Another restriction is that it is not possible to post events that the
-I/O core has not registered an interest in. Trying to do so will cause
-the method to throw an error. See the command handler method
-\fBwatch\fR described in \fBrefchan\fR, the document specifying
-the API of command handlers for reflected channels.
-.PP
-This command is \fBsafe\fR and made accessible to safe interpreters.
-It can trigger the execution of \fBchan event\fR handlers, whether in the
-current interpreter or in other interpreters or other threads, even
-where the event is posted from a safe interpreter and listened for by
-a trusted interpreter. \fBChan event\fR handlers are \fIalways\fR
-executed in the interpreter that set them up.
+For use only by handlers for a channel created by \fBchan create\fR.  It is an
+error to post an event for any other channel.
+.PP
+Since only the handler for a reflected channel channel should post events it is
+an error to post an event from any interpreter other than the interpreter that
+created the channel.
+.PP
+It is an error to post an event that the channel has no interest in.  See
+\fBwatch\fR in the \fBrefchan\fR documentation for more information
+.PP
+\fBchan postevent\fR is available in safe interpreters, as any handler for a
+reflected channel would have been created, and will be evaluated in that
+interpreter as well.
 .RE
 .TP
-\fBchan push \fIchannelId cmdPrefix\fR
-Adds a new transformation on top of the channel \fIchannelId\fR. The
-\fIcmdPrefix\fR argument describes a list of one or more words which represent
-a handler that will be used to implement the transformation. The command
-prefix must provide the API described in the \fBtranschan\fR manual page.
-The result of this subcommand is a handle to the transformation. Note that it
-is important to make sure that the transformation is capable of supporting the
-channel mode that it is used with or this can make the channel neither
-readable nor writable.
-.TP
-\fBchan puts\fR ?\fB\-nonewline\fR? ?\fIchannelId\fR? \fIstring\fR
-.
-Writes \fIstring\fR to the channel named \fIchannelId\fR followed by a
-newline character. A trailing newline character is written unless the
-optional flag \fB\-nonewline\fR is given. If \fIchannelId\fR is
-omitted, the string is written to the standard output channel,
+\fBchan push \fIchannelName cmdPrefix\fR
+Adds a new transformation handler on top of the channel and returns a handle
+for the transformation.  \fIcmdPrefix\fR is the first words of a command that
+provides the interface documented for \fBtranschan\fR, and transforms data on
+the channel, It is an error if handler does not support the mode(s) the channel
+is in.
+.TP
+\fBchan puts\fR ?\fB\-nonewline\fR? ?\fIchannelName\fR? \fIstring\fR
+.
+Writes \fIstring\fR and a line feed to the channel.  If \fB\-nonewline\fR is
+given, the trailing line feed is not written. The default channel is
 \fBstdout\fR.
 .RS
 .PP
-Newline characters in the output are translated by \fBchan puts\fR to
-platform-specific end-of-line sequences according to the currently
-configured value of the \fB\-translation\fR option for the channel
-(for example, on PCs newlines are normally replaced with
-carriage-return-linefeed sequences; see \fBchan configure\fR above for
-details).
-.PP
-Tcl buffers output internally, so characters written with \fBchan
-puts\fR may not appear immediately on the output file or device; Tcl
-will normally delay output until the buffer is full or the channel is
-closed.  You can force output to appear immediately with the \fBchan
-flush\fR command.
-.PP
-When the output buffer fills up, the \fBchan puts\fR command will
-normally block until all the buffered data has been accepted for
-output by the operating system.  If \fIchannelId\fR is in non-blocking
-mode then the \fBchan puts\fR command will not block even if the
-operating system cannot accept the data.  Instead, Tcl continues to
-buffer the data and writes it in the background as fast as the
-underlying file or device can accept it.  The application must use the
-Tcl event loop for non-blocking output to work; otherwise Tcl never
-finds out that the file or device is ready for more output data.  It
-is possible for an arbitrarily large amount of data to be buffered for
-a channel in non-blocking mode, which could consume a large amount of
-memory.  To avoid wasting memory, non-blocking I/O should normally be
-used in an event-driven fashion with the \fBchan event\fR command
-(do not invoke \fBchan puts\fR unless you have recently been notified
-via a file event that the channel is ready for more output data).
+Each line feed in the output is translated according to the configuration of
+\fB\-translation\fR.
+.PP
+Because Tcl internally buffers output, characters written to a channel may not
+immediately be available at the destination.  Tcl normally delays output until
+the buffer is full or the channel is closed. \fBchan flush\fR forces output in
+the direction of the destination.
+.PP
+When the output for a channel in blocking mode fills up, \fBchan puts\fR blocks
+until space in the buffer is available again, but for a channel in non-blocking
+mode, it returns immediately and the data is written in the background as fast
+possible, constrained by the speed at which as the destination accepts it.
+Output to a channel in non-blocking mode only works properly when the
+application enters the event loop, giving Tcl a chance to find out that the
+destination is ready to accept more data.  When a channel is in non-blocking
+mode, Tcl's internal buffers can hold an arbitrary amount of data, possibly
+consuming a large amount of memory.  To avoid wasting memory, channels in
+non-blocking mode should normally be handled using \fBchan event\fR, where the
+application only invokes \fBchan puts\fR after being recently notified through
+a file event handler that the channel is ready for more output data.
 .RE
 .TP
-\fBchan read \fIchannelId\fR ?\fInumChars\fR?
+\fBchan read \fIchannelName\fR ?\fInumChars\fR?
 .TP
-\fBchan read \fR?\fB\-nonewline\fR? \fIchannelId\fR
+\fBchan read \fR?\fB\-nonewline\fR? \fIchannelName\fR
 .
-In the first form, the result will be the next \fInumChars\fR
-characters read from the channel named \fIchannelId\fR; if
-\fInumChars\fR is omitted, all characters up to the point when the
-channel would signal a failure (whether an end-of-file, blocked or
-other error condition) are read. In the second form (i.e. when
-\fInumChars\fR has been omitted) the flag \fB\-nonewline\fR may be
-given to indicate that any trailing newline in the string that has
-been read should be trimmed.
+Reads and returns the next \fInumChars\fR characters from the channel. If
+\fInumChars\fR is omitted, all available characters up to the end of the file
+are read, or if the channel is in non-blocking mode, all currently-available
+characters are read.  If there is an error on the channel, reading ceases and
+an error is returned.  If \fInumChars\fR is not given, \fB\-nonewline\fR
+may be given, causing any any trailing line feed to be trimmed.
 .RS
 .PP
-If \fIchannelId\fR is in non-blocking mode, \fBchan read\fR may not
-read as many characters as requested: once all available input has
-been read, the command will return the data that is available rather
-than blocking for more input.  If the channel is configured to use a
-multi-byte encoding, then there may actually be some bytes remaining
-in the internal buffers that do not form a complete character.  These
-bytes will not be returned until a complete character is available or
-end-of-file is reached.  The \fB\-nonewline\fR switch is ignored if
-the command returns before reaching the end of the file.
-.PP
-\fBChan read\fR translates end-of-line sequences in the input into
-newline characters according to the \fB\-translation\fR option for the
-channel (see \fBchan configure\fR above for a discussion on the ways
-in which \fBchan configure\fR will alter input).
-.PP
-When reading from a serial port, most applications should configure
-the serial port channel to be non-blocking, like this:
-.PP
-.CS
-\fBchan configure \fIchannelId \fB\-blocking \fI0\fR.
-.CE
-.PP
-Then \fBchan read\fR behaves much like described above.  Note that
-most serial ports are comparatively slow; it is entirely possible to
-get a \fBreadable\fR event for each character read from them. Care
-must be taken when using \fBchan read\fR on blocking serial ports:
-.TP
-\fBchan read \fIchannelId numChars\fR
-.
-In this form \fBchan read\fR blocks until \fInumChars\fR have been
-received from the serial port.
-.TP
-\fBchan read \fIchannelId\fR
-.
-In this form \fBchan read\fR blocks until the reception of the
-end-of-file character, see \fBchan configure -eofchar\fR. If there no
-end-of-file character has been configured for the channel, then
-\fBchan read\fR will block forever.
+If the channel is in non-blocking mode, fewer characters than requested may be
+returned.  If the channel is configured to use a multi-byte encoding, bytes
+that do not form a complete character are retained in the buffers until enough
+bytes to complete the character accumulate, or the end of the data is reached.
+\fB\-nonewline\fR is ignored if characters are returned before reaching the end
+of the file.
+.PP
+Each end-of-line sequence according to the value of \fB\-translation\fR is
+translated into a line feed.
+.PP
+When reading from a serial port, most applications should configure the serial
+port channel to be in non-blocking mode, but not necessarily use an event
+handler since most serial ports are comparatively slow.  It is entirely
+possible to get a \fBreadable\fR event for each individual character.  In
+blocking mode, \fBchan read\fR blocks forever when reading to the end of the
+data if there is no \fBchan configure -eofchar\fR configured for the channel.
 .RE
 .TP
-\fBchan seek \fIchannelId offset\fR ?\fIorigin\fR?
+\fBchan seek \fIchannelName offset\fR ?\fIorigin\fR?
 .
-Sets the current access position within the underlying data stream for
-the channel named \fIchannelId\fR to be \fIoffset\fR bytes relative to
-\fIorigin\fR. \fIOffset\fR must be an integer (which may be negative)
-and \fIorigin\fR must be one of the following:
+Sets the current position for the data in the channel to integer \fIoffset\fR
+bytes relative to \fIorigin\fR.  A negative offset moves the current position
+backwards from the origin.  \fIorigin\fR is one of the
+following:
 .RS
+.PP
 .TP 10
 \fBstart\fR
 .
-The new access position will be \fIoffset\fR bytes from the start
-of the underlying file or device.
+The origin is the start of the data.  This is the default.
 .TP 10
 \fBcurrent\fR
 .
-The new access position will be \fIoffset\fR bytes from the current
-access position; a negative \fIoffset\fR moves the access position
-backwards in the underlying file or device.
+The origin is the current position.
 .TP 10
 \fBend\fR
 .
-The new access position will be \fIoffset\fR bytes from the end of the
-file or device.  A negative \fIoffset\fR places the access position
-before the end of file, and a positive \fIoffset\fR places the access
-position after the end of file.
-.PP
-The \fIorigin\fR argument defaults to \fBstart\fR.
+The origin is the end of the data.
 .PP
-\fBChan seek\fR flushes all buffered output for the channel before the
-command returns, even if the channel is in non-blocking mode.  It also
-discards any buffered and unread input.  This command returns an empty
-string.  An error occurs if this command is applied to channels whose
-underlying file or device does not support seeking.
+\fBChan seek\fR flushes all buffered output even if the channel is in
+non-blocking mode, discards any buffered and unread input, and returns the
+empty string or an error if the channel does not support seeking.
 .PP
-Note that \fIoffset\fR values are byte offsets, not character offsets.
-Both \fBchan seek\fR and \fBchan tell\fR operate in terms of bytes,
-not characters, unlike \fBchan read\fR.
+\fIoffset\fR values are byte offsets, not character offsets.  Unlike \fBchan
+read\fR, both \fBchan seek\fR and \fBchan tell\fR operate in terms of bytes,
+not characters,
 .RE
 .TP
-\fBchan tell \fIchannelId\fR
+\fBchan tell \fIchannelName\fR
 .
-Returns a number giving the current access position within the
-underlying data stream for the channel named \fIchannelId\fR. This
-value returned is a byte offset that can be passed to \fBchan seek\fR
-in order to set the channel to a particular position.  Note that this
-value is in terms of bytes, not characters like \fBchan read\fR.  The
-value returned is -1 for channels that do not support seeking.
+Returns the offset in bytes of the current position in the underlying data, or
+-1 if the channel does not suport seeking. The value can be passed to \fBchan
+seek\fR to set current position to that offset.
 .TP
-\fBchan truncate \fIchannelId\fR ?\fIlength\fR?
+\fBchan truncate \fIchannelName\fR ?\fIlength\fR?
 .
-Sets the byte length of the underlying data stream for the channel
-named \fIchannelId\fR to be \fIlength\fR (or to the current byte
-offset within the underlying data stream if \fIlength\fR is
-omitted). The channel is flushed before truncation.
+Flushes the channel and truncates the data in the channel to \fIlength\fR
+bytes, or to the current position in bytes if \fIlength\fR is omitted.
 .
 .SH EXAMPLES
 .PP
-This opens a file using a known encoding (CP1252, a very common encoding
-on Windows), searches for a string, rewrites that part, and truncates the
-file after a further two lines.
+In the following example a file is opened using the encoding CP1252, which is
+common on Windows, searches for a string, rewrites that part, and truncates the
+file two lines later.
 .PP
 .CS
 set f [open somefile.txt r+]
@@ -793,12 +619,12 @@ while {[\fBchan gets\fR $f line] >= 0} {
 \fBchan close\fR $f
 .CE
 .PP
-A network server that does echoing of its input line-by-line without
-preventing servicing of other connections at the same time.
+A network server that echoes its input line-by-line without
+preventing servicing of other connections at the same time:
 .PP
 .CS
 # This is a very simple logger...
-proc log {message} {
+proc log message {
     \fBchan puts\fR stdout $message
 }
 
diff --git a/doc/encoding.n b/doc/encoding.n
index e78a8e7..2277f9d 100644
--- a/doc/encoding.n
+++ b/doc/encoding.n
@@ -14,16 +14,10 @@ encoding \- Manipulate encodings
 .BE
 .SH INTRODUCTION
 .PP
-Strings in Tcl are logically a sequence of 16-bit Unicode characters.
+Strings in Tcl are logically a sequence of Unicode characters.
 These strings are represented in memory as a sequence of bytes that
-may be in one of several encodings: modified UTF\-8 (which uses 1 to 3
-bytes per character), 16-bit
-.QW Unicode
-(which uses 2 bytes per character, with an endianness that is
-dependent on the host architecture), and binary (which uses a single
-byte per character but only handles a restricted range of characters).
-Tcl does not guarantee to always use the same encoding for the same
-string.
+may be in one of several encodings: modified UTF\-8 (which uses 1 to 4
+bytes per character), or a custom encoding start as 8 bit binary data.
 .PP
 Different operating system interfaces or applications may generate
 strings in other encodings such as Shift\-JIS.  The \fBencoding\fR
@@ -34,16 +28,30 @@ formats.
 Performs one of several encoding related operations, depending on
 \fIoption\fR.  The legal \fIoption\fRs are:
 .TP
-\fBencoding convertfrom\fR ?\fIencoding\fR? \fIdata\fR
+\fBencoding convertfrom\fR ?\fB-nocomplain\fR? ?\fB-failindex var\fR?
+?\fIencoding\fR? \fIdata\fR
 .
-Convert \fIdata\fR to Unicode from the specified \fIencoding\fR.  The
-characters in \fIdata\fR are treated as binary data where the lower
-8-bits of each character is taken as a single byte.  The resulting
-sequence of bytes is treated as a string in the specified
-\fIencoding\fR.  If \fIencoding\fR is not specified, the current
+Convert \fIdata\fR to a Unicode string from the specified \fIencoding\fR.  The
+characters in \fIdata\fR are 8 bit binary data.  The resulting
+sequence of bytes is a string created by applying the given \fIencoding\fR
+to the data. If \fIencoding\fR is not specified, the current
 system encoding is used.
+.
+The call fails on convertion errors, like an incomplete utf-8 sequence.
+The option \fB-failindex\fR is followed by a variable name. The variable
+is set to \fI-1\fR if no conversion error occured. It is set to the
+first error location in \fIdata\fR in case of a conversion error. All data
+until this error location is transformed and retured. This option may not
+be used together with \fB-nocomplain\fR.
+.
+The call does not fail on conversion errors, if the option
+\fB-nocomplain\fR is given. In this case, any error locations are replaced
+by \fB?\fR. Incomplete sequences are written verbatim to the output string.
+The purpose of this switch is to gain compatibility to prior versions of TCL.
+It is not recommended for any other usage.
 .TP
-\fBencoding convertto\fR ?\fIencoding\fR? \fIstring\fR
+\fBencoding convertto\fR ?\fB-nocomplain\fR? ?\fB-failindex var\fR?
+?\fIencoding\fR? \fIstring\fR
 .
 Convert \fIstring\fR from Unicode to the specified \fIencoding\fR.
 The result is a sequence of bytes that represents the converted
@@ -51,6 +59,21 @@ string.  Each byte is stored in the lower 8-bits of a Unicode
 character (indeed, the resulting string is a binary string as far as
 Tcl is concerned, at least initially).  If \fIencoding\fR is not
 specified, the current system encoding is used.
+.
+The call fails on convertion errors, like a Unicode character not representable
+in the given \fIencoding\fR.
+.
+The option \fB-failindex\fR is followed by a variable name. The variable
+is set to \fI-1\fR if no conversion error occured. It is set to the
+first error location in \fIdata\fR in case of a conversion error. All data
+until this error location is transformed and retured. This option may not
+be used together with \fB-nocomplain\fR.
+.
+The call does not fail on conversion errors, if the option
+\fB-nocomplain\fR is given. In this case, any error locations are replaced
+by \fB?\fR. Incomplete sequences are written verbatim to the output string.
+The purpose of this switch is to gain compatibility to prior versions of TCL.
+It is not recommended for any other usage.
 .TP
 \fBencoding dirs\fR ?\fIdirectoryList\fR?
 .
@@ -90,6 +113,26 @@ set s [\fBencoding convertfrom\fR euc-jp "\exA4\exCF"]
 The result is the unicode codepoint:
 .QW "\eu306F" ,
 which is the Hiragana letter HA.
+.PP
+The following example detects the error location in an incomplete UTF-8 sequence:
+.PP
+.CS
+% set s [\fBencoding convertfrom\fR -failindex i utf-8 "A\xc3"]
+A
+% set i
+1
+.CE
+.PP
+The following example detects the error location while transforming to ISO8859-1
+(ISO-Latin 1):
+.PP
+.CS
+% set s [\fBencoding convertto\fR -failindex i utf-8 "A\u0141"]
+A
+% set i
+1
+.CE
+.PP
 .SH "SEE ALSO"
 Tcl_GetEncoding(3)
 .SH KEYWORDS
diff --git a/doc/expr.n b/doc/expr.n
index 43ad26f..490217c 100644
--- a/doc/expr.n
+++ b/doc/expr.n
@@ -17,7 +17,7 @@ expr \- Evaluate an expression
 .BE
 .SH DESCRIPTION
 .PP
-The \fIexpr\fR command concatenates \fIarg\fRs, separated by a space, into an expression, and evaluates
+Concatenates \fIarg\fRs, separated by a space, into an expression, and evaluates
 that expression, returning its value.
 The operators permitted in an expression include a subset of
 the operators permitted in C expressions.  For those operators
@@ -37,76 +37,36 @@ operands are specified.  Expressions also support
 non-numeric operands, string comparisons, and some
 additional operators not found in C.
 .PP
-When an expression evaluates to an integer, the value is the decimal form of
-the integer, and when an expression evaluates to a floating-point number, the
-value is the form produced by the \fB%g\fR format specifier of Tcl's
-\fBformat\fR command.
+When the result of expression is an integer, it is in decimal form, and when
+the result is a floating-point number, it is in the form produced by the
+\fB%g\fR format specifier of \fBformat\fR.
 .PP
 .VS "TIP 582"
-You can use \fB#\fR at any point in the expression (except inside double
-quotes or braces) to start a comment. Comments last to the end of the line or
+At any point in the expression except within double quotes or braces, \fB#\fR
+is the beginning of a comment, which lasts to the end of the line or
 the end of the expression, whichever comes first.
 .VE "TIP 582"
 .SS OPERANDS
 .PP
 An expression consists of a combination of operands, operators, parentheses and
 commas, possibly with whitespace between any of these elements, which is
-ignored.
+ignored.  Each operand is intepreted as a numeric value if at all possible.
 .PP
-An operand may be specified in any of the following ways:
-.IP [1]
-As a numeric value, either integer or floating-point.
-.IP [2]
-As a boolean value, using any form understood by \fBstring is\fR
-\fBboolean\fR.
-.IP [3]
-As a variable, using standard \fB$\fR notation.
-The value of the variable is then the value of the operand.
-.IP [4]
-As a string enclosed in double-quotes.
-Backslash, variable, and command substitution are performed as described in
-\fBTcl\fR.
-.IP [5]
-As a string enclosed in braces.
-The operand is treated as a braced value as described in \fBTcl\fR.
-.IP [6]
-As a Tcl command enclosed in brackets.
-Command substitution is performed as described in \fBTcl\fR.
-.IP [7]
-As a mathematical function such as \fBsin($x)\fR, whose arguments have any of the above
-forms for operands.  See \fBMATH FUNCTIONS\fR below for
-a discussion of how mathematical functions are handled.
-.PP
-Because \fBexpr\fR parses and performs substitutions on values that have
-already been parsed and substituted by \fBTcl\fR, it is usually best to enclose
-expressions in braces to avoid the first round of substitutions by
-\fBTcl\fR.
-.PP
-Below are some examples of simple expressions where the value of \fBa\fR is 3
-and the value of \fBb\fR is 6.  The command on the left side of each line
-produces the value on the right side.
-.PP
-.CS
-.ta 9c
-\fBexpr\fR {3.1 + $a}	\fI6.1\fR
-\fBexpr\fR {2 + "$a.$b"}	\fI5.6\fR
-\fBexpr\fR {4*[llength "6 2"]}	\fI8\fR
-\fBexpr\fR {{word one} < "word $a"}	\fI0\fR
-.CE
-.PP
-\fBInteger value\fR
+Each operand has one of the following forms:
+.RS
 .PP
-An integer operand may be specified in decimal (the normal case, the optional
-first two characters are \fB0d\fR), binary
-(the first two characters are \fB0b\fR), octal
-(the first two characters are \fB0o\fR), or hexadecimal
-(the first two characters are \fB0x\fR) form.  For
-compatibility with older Tcl releases, an operand that begins with \fB0\fR is
-interpreted as an octal integer even if the second character is not \fBo\fR.
+.TP
+A \fBnumeric value\fR
 .PP
-\fBFloating-point value\fR
+.RS
+.
+Either integer or floating-point.  The first two characters of an integer may
+also be \fB0d\fR for decimal, \fB0b\fR for binary, \fB0o\fR for octal or
+\fB0x\fR for hexadicimal.  For compatibility with older Tcl releases, an
+operand that begins with \fB0\fR is interpreted as an octal integer even if the
+second character is not \fBo\fR.
 .PP
-A floating-point number may be specified in any of several
+A floating-point number may be take any of several
 common decimal formats, and may use the decimal point \fB.\fR,
 \fBe\fR or \fBE\fR for scientific notation, and
 the sign characters \fB+\fR and \fB\-\fR.  The
@@ -116,16 +76,9 @@ and \fBNaN\fR, in any combination of case, are also recognized as floating point
 values.  An operand that doesn't have a numeric interpretation must be quoted
 with either braces or with double quotes.
 .PP
-\fBBoolean value\fR
-.PP
-A boolean value may be represented by any of the values \fB0\fR, \fBfalse\fR, \fBno\fR,
-or \fBoff\fR and any of the values \fB1\fR, \fBtrue\fR, \fByes\fR, or \fBon\fR.
-.PP
-\fBDigit Separator\fR
-.PP
 Digits in any numeric value may be separated with one or more underscore
-characters, "\fB_\fR", to improve readability.  These separators may only
-appear between digits.  The separator may not appear at the start of a
+characters, "\fB_\fR".  A separator may only
+appear between digits, not appear at the start of a
 numeric value, between the leading 0 and radix specifier, or at the
 end of a numeric value.  Here are some examples:
 .PP
@@ -135,6 +88,54 @@ end of a numeric value.  Here are some examples:
 \fBexpr\fR 0xffff_ffff		\fI4294967295\fR
 \fBformat\fR 0x%x 0b1111_1110_1101_1011		\fI0xfedb\fR
 .CE
+.RE
+
+.TP
+A \fBboolean value\fR
+.
+Using any form understood by \fBstring is\fR
+\fBboolean\fR.
+.TP
+A \fBvariable\fR
+.
+Using standard \fB$\fR notation.
+The value of the variable is the value of the operand.
+.TP
+A string enclosed in \fBdouble-quotes\fR
+.
+Backslash, variable, and command substitution are performed according to the
+rules for \fBTcl\fR.
+.TP
+A string enclosed in \fBbraces\fR.
+The operand is treated as a braced value according to the rule for braces in
+\fBTcl\fR.
+.TP
+A Tcl command enclosed in \fBbrackets\fR
+.
+Command substitution is performed as according to the command substitution rule
+for \fBTcl\fR.
+.TP
+A mathematical function such as \fBsin($x)\fR, whose arguments have any of the above
+forms for operands.  See \fBMATH FUNCTIONS\fR below for
+a discussion of how mathematical functions are handled.
+.RE
+.PP
+Because \fBexpr\fR parses and performs substitutions on values that have
+already been parsed and substituted by \fBTcl\fR, it is usually best to enclose
+expressions in braces to avoid the first round of substitutions by
+\fBTcl\fR.
+.PP
+Below are some examples of simple expressions where the value of \fBa\fR is 3
+and the value of \fBb\fR is 6.  The command on the left side of each line
+produces the value on the right side.
+.PP
+.CS
+.ta 9c
+\fBexpr\fR {3.1 + $a}	\fI6.1\fR
+\fBexpr\fR {2 + "$a.$b"}	\fI5.6\fR
+\fBexpr\fR {4*[llength {6 2}]}	\fI8\fR
+\fBexpr\fR {{word one} < "word $a"}	\fI0\fR
+.CE
 .PP
 .SS OPERATORS
 .PP
diff --git a/doc/http.n b/doc/http.n
index 0ba6be2..4781a1b 100644
--- a/doc/http.n
+++ b/doc/http.n
@@ -49,6 +49,14 @@ http \- Client-side implementation of the HTTP/1.1 protocol
 \fB::http::registerError \fIport\fR ?\fImessage\fR?
 .sp
 \fB::http::unregister \fIproto\fR
+.SH "EXPORTED COMMANDS"
+.PP
+Namespace \fBhttp\fR exports the commands \fBconfig\fR, \fBformatQuery\fR,
+\fBgeturl\fR, \fBquoteString\fR, \fBregister\fR, \fBregisterError\fR,
+\fBreset\fR, \fBunregister\fR, and \fBwait\fR.
+.PP
+It does not export the commands \fBcleanup\fR, \fBcode\fR, \fBdata\fR,
+\fBerror\fR, \fBmeta\fR, \fBncode\fR, \fBsize\fR, or \fBstatus\fR.
 .BE
 .SH DESCRIPTION
 .PP
@@ -79,8 +87,9 @@ must be active.  In Tk applications this is always true.  For pure-Tcl
 applications, the caller can use \fB::http::wait\fR after calling
 \fB::http::geturl\fR to start the event loop.
 .PP
-\fBNote:\fR The event queue is even used without the \fB-command\fR option.
-As a side effect, arbitrary commands may be processed while \fBhttp::geturl\fR is running.
+\fBNote:\fR The event queue is even used without the \fB\-command\fR option.
+As a side effect, arbitrary commands may be processed while \fBhttp::geturl\fR
+is running.
 .SH COMMANDS
 .TP
 \fB::http::config\fR ?\fIoptions\fR?
@@ -120,9 +129,9 @@ is 1.
 \fB\-postfresh\fR \fIboolean\fR
 .
 Specifies whether requests that use the \fBPOST\fR method will always use a
-fresh socket, overriding the \fB-keepalive\fR option of
-command \fBhttp::geturl\fR.  See the \fBPERSISTENT SOCKETS\fR section for details.
-The default is 0.
+fresh socket, overriding the \fB\-keepalive\fR option of
+command \fBhttp::geturl\fR.  See the \fBPERSISTENT SOCKETS\fR section for
+details. The default is 0.
 .TP
 \fB\-proxyhost\fR \fIhostname\fR
 .
@@ -144,6 +153,13 @@ the proxy server and proxy port.  Otherwise the filter should return
 an empty list.  The default filter returns the values of the
 \fB\-proxyhost\fR and \fB\-proxyport\fR settings if they are
 non-empty.
+.RS
+.PP
+The \fB::http::geturl\fR command runs the \fB\-proxyfilter\fR callback inside
+a \fBcatch\fR command.  Therefore an error in the callback command does
+not call the \fBbgerror\fR handler.  See the \fBERRORS\fR section for
+details.
+.RE
 .TP
 \fB\-repost\fR \fIboolean\fR
 .
@@ -161,12 +177,7 @@ default is 0.
 .
 The \fIencoding\fR used for creating the x-url-encoded URLs with
 \fB::http::formatQuery\fR and \fB::http::quoteString\fR.
-The default is \fButf-8\fR, as specified by RFC
-2718.  Prior to http 2.5 this was unspecified, and that behavior can be
-returned by specifying the empty string (\fB{}\fR), although
-\fIiso8859-1\fR is recommended to restore similar behavior but without the
-\fB::http::formatQuery\fR or \fB::http::quoteString\fR
-throwing an error processing non-latin-1 characters.
+The default is \fButf-8\fR, as specified by RFC 2718.
 .TP
 \fB\-useragent\fR \fIstring\fR
 .
@@ -182,9 +193,9 @@ numbers of \fBhttp\fR and \fBTcl\fR.
 .
 If the value is boolean \fBtrue\fR, then by default requests will send a header
 .QW "\fBAccept-Encoding: gzip,deflate,compress\fR" .
-If the value is boolean \fBfalse\fR, then by default this header will not be sent.
-In either case the default can be overridden for an individual request by
-supplying a custom \fBAccept-Encoding\fR header in the \fB-headers\fR option
+If the value is boolean \fBfalse\fR, then by default this header will not be
+sent.  In either case the default can be overridden for an individual request by
+supplying a custom \fBAccept-Encoding\fR header in the \fB\-headers\fR option
 of \fBhttp::geturl\fR. The default is 1.
 .RE
 .TP
@@ -237,6 +248,11 @@ proc httpCallback {token} {
     # Access state as a Tcl array
 }
 .CE
+.PP
+The \fB::http::geturl\fR command runs the \fB\-command\fR callback inside
+a \fBcatch\fR command.  Therefore an error in the callback command does
+not call the \fBbgerror\fR handler.  See the \fBERRORS\fR section for
+details.
 .RE
 .TP
 \fB\-handler\fR \fIcallback\fR
@@ -263,9 +279,21 @@ proc httpHandlerCallback {socket token} {
 }
 .CE
 .PP
-The \fBhttp::geturl\fR code for the \fB-handler\fR option is not compatible with either compression or chunked transfer-encoding.  If \fB-handler\fR is specified, then to work around these issues \fBhttp::geturl\fR will reduce the HTTP protocol to 1.0, and override the \fB-zip\fR option (i.e. it will not send the header "\fBAccept-Encoding: gzip,deflate,compress\fR").
+The \fBhttp::geturl\fR code for the \fB\-handler\fR option is not compatible
+with either compression or chunked transfer-encoding.  If \fB\-handler\fR is
+specified, then to work around these issues \fBhttp::geturl\fR will reduce the
+HTTP protocol to 1.0, and override the \fB\-zip\fR option (i.e. it will not
+send the header "\fBAccept-Encoding: gzip,deflate,compress\fR").
 .PP
-If options \fB-handler\fR and \fB-channel\fR are used together, the handler is responsible for copying the data from the HTTP socket to the specified channel.  The name of the channel is available to the handler as element \fB-channel\fR of the token array.
+If options \fB\-handler\fR and \fB\-channel\fR are used together, the handler
+is responsible for copying the data from the HTTP socket to the specified
+channel.  The name of the channel is available to the handler as element
+\fB\-channel\fR of the token array.
+.PP
+The \fB::http::geturl\fR command runs the \fB\-handler\fR callback inside
+a \fBcatch\fR command.  Therefore an error in the callback command does
+not call the \fBbgerror\fR handler.  See the \fBERRORS\fR section for
+details.
 .RE
 .TP
 \fB\-headers\fR \fIkeyvaluelist\fR
@@ -293,8 +321,16 @@ multiple requests.  Default is 0.
 \fB\-method\fR \fItype\fR
 .
 Force the HTTP request method to \fItype\fR. \fB::http::geturl\fR will
-auto-select GET, POST or HEAD based on other options, but this option
-enables choices like PUT and DELETE for webdav support.
+auto-select GET, POST or HEAD based on other options, but this option overrides
+that selection and enables choices like PUT and DELETE for WebDAV support.
+.RS
+.PP
+It is the caller's responsibility to ensure that the headers and request body
+(if any) conform to the requirements of the request method.  For example, if
+using \fB\-method\fR \fIPOST\fR to send a POST with an empty request body, the
+caller must also supply the option
+.QW "\-headers {Content-Length 0}" .
+.RE
 .TP
 \fB\-myaddr\fR \fIaddress\fR
 .
@@ -327,12 +363,21 @@ otherwise complain about HTTP/1.1.
 .TP
 \fB\-query\fR \fIquery\fR
 .
-This flag causes \fB::http::geturl\fR to do a POST request that passes the
-\fIquery\fR as payload verbatim to the server.
-The content format (and encoding) of \fIquery\fR is announced by the header
-field \fBcontent-type\fR set by the option \fB-type\fR.
-\fIquery\fR is an x-url-encoding formatted query, if used for html forms.
-The \fB::http::formatQuery\fR procedure can be used to do the formatting.
+This flag (if the value is non-empty) causes \fB::http::geturl\fR to do a
+POST request that passes the string
+\fIquery\fR verbatim to the server as the request payload.
+The content format (and encoding) of \fIquery\fR is announced by the request
+header \fBContent-Type\fR which is set by the option \fB\-type\fR.  Any value
+of \fB\-type\fR is permitted, and it is the responsibility of the caller to
+supply \fIquery\fR in the correct format.
+.RS
+.PP
+If \fB\-type\fR is not specified, it defaults to
+\fIapplication/x-www-form-urlencoded\fR, which requires \fIquery\fR to be an
+x-url-encoding formatted query-string (this \fB\-type\fR and query format are
+used in a POST submitted from an html form).  The \fB::http::formatQuery\fR
+procedure can be used to do the formatting.
+.RE
 .TP
 \fB\-queryblocksize\fR \fIsize\fR
 .
@@ -531,6 +576,14 @@ to know the result of the asynchronous HTTP request, it can call
 \fB::http::wait\fR and then check status and error, just as the
 callback does.
 .PP
+The \fB::http::geturl\fR command runs the \fB\-command\fR, \fB\-handler\fR,
+and \fB\-proxyfilter\fR callbacks inside a \fBcatch\fR command.  Therefore
+an error in the callback command does not call the \fBbgerror\fR handler.
+When debugging one of these
+callbacks, it may be convenient to report errors by using a
+\fBcatch\fR command within the callback command itself, e.g. to write
+an error message to stdout.
+.PP
 In any case, you must still call
 \fB::http::cleanup\fR to delete the state array when you are done.
 .PP
@@ -601,7 +654,8 @@ if the HTTP response is text.
 \fBbody\fR
 .
 The contents of the URL.  This will be empty if the \fB\-channel\fR
-option has been specified.  This value is returned by the \fB::http::data\fR command.
+option has been specified.  This value is returned by the \fB::http::data\fR
+command.
 .TP
 \fBcharset\fR
 .
@@ -713,9 +767,9 @@ whether the server was modified by the failed POST request, before
 sending the same request again.
 .PP
 A HTTP request will use a persistent socket if the call to
-\fBhttp::geturl\fR has the option \fB-keepalive true\fR. It will use
+\fBhttp::geturl\fR has the option \fB\-keepalive true\fR. It will use
 pipelining where permitted if the \fBhttp::config\fR option
-\fB-pipeline\fR is boolean \fBtrue\fR (its default value).
+\fB\-pipeline\fR is boolean \fBtrue\fR (its default value).
 .PP
 The http package maintains no more than one persistent connection to each
 server (i.e. each value of
@@ -737,8 +791,8 @@ In accordance with RFC 7230, \fBhttp::geturl\fR does not pipeline
 requests that use the POST method.  If a POST uses a persistent
 connection and is not the first request on that connection,
 \fBhttp::geturl\fR waits until it has received the response for the previous
-request; or (if \fBhttp::config\fR option \fB-postfresh\fR is boolean \fBtrue\fR) it
-uses a new connection for each POST.
+request; or (if \fBhttp::config\fR option \fB\-postfresh\fR is boolean
+\fBtrue\fR) it uses a new connection for each POST.
 .PP
 If the server is processing a number of pipelined requests, and sends a
 response header
@@ -758,7 +812,7 @@ GET requests, \fBhttp::geturl\fR opens another connection and retransmits
 the failed request. However, if the request was a POST, RFC 7230 forbids
 automatic retry by default, suggesting either user confirmation, or
 confirmation by user-agent software that has semantic understanding of
-the application.  The \fBhttp::config\fR option \fB-repost\fR allows for
+the application.  The \fBhttp::config\fR option \fB\-repost\fR allows for
 either possibility.
 .PP
 Asynchronous close events can occur only in a short interval of time.  The
@@ -766,35 +820,36 @@ Asynchronous close events can occur only in a short interval of time.  The
 server.  Upon detection, the connection is also closed at the client end,
 and subsequent requests will use a fresh connection.
 .PP
-If the \fBhttp::geturl\fR command is called with option \fB-keepalive true\fR,
+If the \fBhttp::geturl\fR command is called with option \fB\-keepalive true\fR,
 then it will both try to use an existing persistent connection
 (if one is available), and it will send the server a
 .QW "\fBConnection: keep-alive\fR"
 request header asking to keep the connection open for future requests.
 .PP
-The \fBhttp::config\fR options \fB-pipeline\fR, \fB-postfresh\fR, and
-\fB-repost\fR relate to persistent connections.
+The \fBhttp::config\fR options \fB\-pipeline\fR, \fB\-postfresh\fR, and
+\fB\-repost\fR relate to persistent connections.
 .PP
-Option \fB-pipeline\fR, if boolean \fBtrue\fR, will pipeline GET and HEAD requests
-made
-over a persistent connection.  POST requests will not be pipelined - if the
+Option \fB\-pipeline\fR, if boolean \fBtrue\fR, will pipeline GET and HEAD
+requests made over a persistent connection.  POST requests will not be
+pipelined - if the
 POST is not the first transaction on the connection, its request will not
 be sent until the previous response has finished.  GET and HEAD requests
 made after a POST will not be sent until the POST response has been
 delivered, and will not be sent if the POST fails.
 .PP
-Option \fB-postfresh\fR, if boolean \fBtrue\fR, will override the \fBhttp::geturl\fR option
-\fB-keepalive\fR, and always open a fresh connection for a POST request.
+Option \fB\-postfresh\fR, if boolean \fBtrue\fR, will override the
+\fBhttp::geturl\fR option \fB\-keepalive\fR, and always open a fresh connection
+for a POST request.
 .PP
-Option \fB-repost\fR, if \fBtrue\fR, permits automatic retry of a POST request
+Option \fB\-repost\fR, if \fBtrue\fR, permits automatic retry of a POST request
 that fails because it uses a persistent connection that the server has
 half-closed (an
 .QW "asynchronous close event" ).
 Subsequent GET and HEAD requests in a failed pipeline will also be retried.
-\fIThe -repost option should be used only if the application understands
+\fIThe \-repost option should be used only if the application understands
 that the retry is appropriate\fR - specifically, the application must know
-that if the failed POST successfully modified the state of the server, a repeat POST
-would have no adverse effect.
+that if the failed POST successfully modified the state of the server, a repeat
+POST would have no adverse effect.
 .VS TIP406
 .SH "COOKIE JAR PROTOCOL"
 .PP
@@ -897,6 +952,40 @@ request.
 Other keys may always be ignored; they have no meaning in this protocol.
 .RE
 .VE TIP406
+.SH "PROTOCOL UPGRADES"
+.PP
+The HTTP/1.1 \fBConnection\fR and \fBUpgrade\fR client headers inform the server
+that the client wishes to change the protocol used over the existing connection
+(RFC 7230).  This mechanism can be used to request a WebSocket (RFC 6455), a
+higher version of the HTTP protocol (HTTP 2), or TLS encryption.  If the
+server accepts the upgrade request, its response code will be 101.
+.PP
+To request a protocol upgrade when calling \fBhttp::geturl\fR, the \fB\-headers\fR
+option must supply appropriate values for \fBConnection\fR and \fBUpgrade\fR, and
+the \fB\-command\fR option must supply a command that implements the requested
+protocol and can also handle the server response if the server refuses the
+protocol upgrade.  For upgrade requests \fBhttp::geturl\fR ignores the value of
+option \fB\-keepalive\fR, and always uses the value \fB0\fR so that the upgrade
+request is not made over a connection that is intended for multiple HTTP requests.
+.PP
+The Tcllib library \fBwebsocket\fR implements WebSockets, and makes the necessary
+calls to commands in the \fBhttp\fR package.
+.PP
+There is currently no native Tcl client library for HTTP/2.
+.PP
+The \fBUpgrade\fR mechanism is not used to request TLS in web browsers, because
+\fBhttp\fR and \fBhttps\fR are served over different ports.  It is used by
+protocols such as Internet Printing Protocol (IPP) that are built on top of
+\fBhttp(s)\fR and use the same TCP port number for both secure and insecure
+traffic.
+.PP
+In browsers, opportunistic encryption is instead implemented by the
+\fBUpgrade-Insecure-Requests\fR client header.  If a secure service is available,
+the server response code is a 307 redirect, and the response header
+\fBLocation\fR specifies the target URL.  The browser must call \fBhttp::geturl\fR
+again in order to fetch this URL.
+See https://w3c.github.io/webappsec-upgrade-insecure-requests/
+.PP
 .SH EXAMPLE
 .PP
 This example creates a procedure to copy a URL to a file while printing a
@@ -932,7 +1021,7 @@ proc httpcopy { url file {chunk 4096} } {
     return $token
 }
 proc httpCopyProgress {args} {
-    puts -nonewline stderr .
+    puts \-nonewline stderr .
     flush stderr
 }
 .CE
diff --git a/doc/info.n b/doc/info.n
index a23cf3a..86263db 100644
--- a/doc/info.n
+++ b/doc/info.n
@@ -68,8 +68,6 @@ that represents an instance of \fBoo::object\fR or one of its subclasses.
 \fIcommandName\fR was created by \fBinterp create\fR.
 .IP \fBzlibStream\fR
 \fIcommandName\fR was created by \fBzlib stream\fR.
-.PP
-Other types may be also registered as well.  See \fBTcl_RegisterCommandTypeName\fR.
 .RE
 .VE TIP426
 .TP
diff --git a/doc/msgcat.n b/doc/msgcat.n
index ac6dde7..c39dc87 100644
--- a/doc/msgcat.n
+++ b/doc/msgcat.n
@@ -73,7 +73,7 @@ the application source code.  New languages
 or locales may be provided by adding a new file to
 the message catalog.
 .PP
-\fBmsgcat\fR distinguises packages by its namespace.
+\fBmsgcat\fR distinguishes packages by its namespace.
 Each package has its own message catalog and configuration settings in \fBmsgcat\fR.
 .PP
 A \fIlocale\fR is a specification string describing a user language like \fBde_ch\fR for Swiss German.
@@ -224,9 +224,7 @@ As an example, the user may prefer French or English text. This may be configure
 This group of commands manage the list of loaded locales for packages not setting a package locale.
 .PP
 .RS
-The subcommand \fBget\fR returns the list of currently loaded locales.
-.PP
-The subcommand \fBpresent\fR requires the argument \fIlocale\fR and returns true, if this locale is loaded.
+The subcommand \fBloaded\fR returns the list of currently loaded locales.
 .PP
 The subcommand \fBclear\fR removes all locales and their data, which are not in the current preference list.
 .RE
@@ -235,7 +233,7 @@ The subcommand \fBclear\fR removes all locales and their data, which are not in
 .
 .VS "TIP 412"
 Searches the specified directory for files that match
-the language specifications returned by \fB::msgcat::mcloadedlocales get\fR
+the language specifications returned by \fB::msgcat::mcloadedlocales loaded\fR
 (or \fBmsgcat::mcpackagelocale preferences\fR if a package locale is set) (note that these are all lowercase), extended by the file extension
 .QW .msg .
 Each matching file is
diff --git a/doc/try.n b/doc/try.n
index eae4dc7..992dcea 100644
--- a/doc/try.n
+++ b/doc/try.n
@@ -87,7 +87,7 @@ Handle different reasons for a file to not be openable for reading:
 .PP
 .CS
 \fBtry\fR {
-    set f [open /some/file/name w]
+    set f [open /some/file/name r]
 } \fBtrap\fR {POSIX EISDIR} {} {
     puts "failed to open /some/file/name: it's a directory"
 } \fBtrap\fR {POSIX ENOENT} {} {