Minor fixups (typos, formatting) to a few existing documentation files (#1470)

* Mostly minor fixups (typos, formatting) to a few existing documentation files

Plus converting the Unicode documentation from TXT to formatted

* Update UNICODE.TEDIT

Previous version did not have page-looks (heading location etc.)

* UNICODE.TEDIT:  write unbreakable charlook property

* Delete UNICODE.TEDIT

Master has a newer version, trying to eliminate conflict

library/UNICODE.TXT

@@ -1,98 +0,0 @@
-This file describes the UNICODE Lisp Library package.
-
-Contributed by Ron Kaplan, August 2020.
-
-The UNICODE library package defines external file formats that enable Medley to read and write files where 16 bit character codes are represented as UTF8 byte sequences or big-endian UTF16 byte-pairs.  It also provides for character codes to be converted (on reading) from Unicode codes to equivalent codes in the Medley-internal Xerox Character Code Standard (XCCS) and (on writing) from XCCS codes to equivalent Unicode codes.
-
-Four external formats are defined when the package is loaded:
-
-  :UTF8	        codes are represented as UTF8 byte sequences and XCCS/Unicode character
-  				conversion takes place.
-
-  :UTF16BE      codes are represented as 2-byte pairs, with the high order by appearing
-			    first in the file, and characters are converted.
-			    
-The two other external formats translate byte sequences into codes, but do not translate the codes.  These allow Medley to see and process characters in their native encoding.
-
-  :UTF8-RAW     codes are represented as UTF8 byte sequences, but character conversion
-			    does not take place.
-
-  :UTF16BE-RAW  codes are represented as big-ending 2-byte pairs but there is no
-                conversion.
-
-These formats all define the end-of-line convention (mostly for writing) for the external files according to the variable EXTERNALEOL (LF, CR, CRLF), with LF the default.
-
-The external format can be specified as a parameter when a stream is opened:
-
-    (OPENSTREAM 'foo.txt 'INPUT 'OLD '((EXTERNALFORMAT :UTF8)))
-
-    (CL:OPEN 'foo.txt :DIRECTION :INPUT :EXTERNAL-FORMAT :UTF8)
-  
-The function STREAMPROP obtains or changes the external format of an open stream:
-
-	(STREAMPROP stream 'EXTERNALFORMAT)  -> :XCCS
-	
-	(STREAMPROP stream 'EXTERNALFORMAT :UTF8) -> :XCCS
-	
-In the latter case, the stream's format is changed to :UTF8 and the previous value is returned, in this example it is Medley's historical default format :XCCS.
-
-Entries can be placed on the variable *DEFAULT-EXTERNALFORMATS* to change the external format that is set by default when a file is opened on a particular device.  Loading UNICODE executes
-
-	(PUSH *DEFAULT-EXTERNALFORMATS* '(UNIX :UTF8))
-
-so that all files opened (by OPENSTREAM, CL:OPEN, etc.) on the UNIX file device will be initialized with :UTF8.  Note that the UNIX and DSK file devices reference the same files (although some caution is needed because {UNIX} does not simulate Medley versioning), but the device name in a file name ({UNIX}/Users/... vs. {DSK}/Users/...) selects one or the other. The default setting above applies only to files specified with {UNIX}; a separate default entry for DSK must be established to change its default from :XCCS. 
-
-The user can also specify the external format on a per-stream basis by putting a function on the list STREAM-AFTER-OPEN-FNS. After OPENSTREAM opens a stream and just before it is returned to the calling function, the functions on that list are applied in order to arguments STREAM, ACCESS, PARAMETERS. They can examine and/or change the properties of the stream, in particular, by calling STREAMPROP to change the external format from its device default.
-
-The XCCS/Unicode mapping tables are defined by the code-mapping files for particular XCCS character sets.  These are typically located in the Library sister directory
-
-	../Unicode/Xerox/
-	
-and the variable UNICODEDIRECTORIES is initialized with a globally valid reference to that path.  The global reference is constructed by prepending the value of the Unix environment-variable "MEDLEYDIR" to the suffix /Unicode/Xerox/.  MEDLEYDIR should be set by the Medley start-up shell script (e.g. /Users/kaplan/local/medley3.5/lispcore/)
-
-The mapping files have conventional names of the form XCCS-<charsetnum>=<charsetname>.TXT, for example, XCCS-0=LATIN.TXT, XCCS-357=SYMBOLS4.TXT.  The translations used by the external formats are read from these files by the function
-
-	(READ-UNICODE-MAPPING FILESPEC NOPRINT NOERROR) 
-	
-where FILESPEC can be a list of files, charset octal strings ("0" "357"), or XCCS charset names (LATIN EXTENDED-LATIN). Reading will be silent if NOPRINT, and the process will not abort if an error occurs and NOERROR.  The value is a flat list of the mappings for all the character sets, with elements of the form (XCCC-code Unicode-code). 
-
-When UNICODE is loaded the mappings for the character sets specified in the variable DEFAULT-XCCS-CHARSETS are installed.  This is initialized to
-
-    (LATIN SYMBOLS1 SYMBOLS2 EXTENDED-LATIN FORMS SYMBOLS3 SYMBOLS4 ACCENTED-LATIN GREEK)
-    
-but DEFAULT-XCCS-CHARSETS can be set to a different collection before UNICODE is loaded.
-
-The internal translation tables used by the external formats are constructed from a list of correspondence pairs by the function
-
-	(MAKE-UNICODE-TRANSLATION-TABLES MAPPING [FROM-XCCS-VAR][TO-XCCS-VAR])
-	
-This returns a list of two arrays (XCCS-to-Unicode Unicode-to-XCCS)containing the relevant translation information organized for rapid access.  If the optional from/to-variables arguments are provide, they are the names of variables whose top-level values will be set to these arrays, for convenience. For the external formats defined above, these variables are *XCCSTOUNICODE* and *UNICODETOXCCS*.
-
-The macro
-
-	(UNICODE.TRANSLATE CODE TRANSLATION-TABLE)
-	
-is used by the external formats to perform the mappings described by the translation-tables.
-
-The following utilities are provided for lower-level manipulation of codes and strings 
-
-	(XTOUCODE XCCSCODE) -> corresponding Unicode
-	(UTOXCODE UNICODE) -> corresponding XCCS code
-	(NUTF8CODEBYTES N) -> number of bytes in the UTF8 representation of N
-	(NUTF8STRINGBYTES STRING RAWFLG) -> number of UTF8 bytes in the UTF8
-	      representation of STRING, translating XCCS to Unicode unless RAWFLG.
-	(XTOUSTRING XCCSSTRING RAWFLG) -> The string of bytes in the UTF8 representation
-	      of the characters in XCCSSTRING (= the bytes in its UTF8 file encoding)
-	(HEXSTRING N WIDTH) -> the hex string for N, padded to WIDTH
-	
-
-The UNICODE file also contains a function for writing a mapping file given a list of mapping pairs. The function
-
-     (WRITE-TRANSLATION-TABLE MAPPING [INCLUDEDCHARSETS] [FILE])
-     
-produces one or more mapping files for the mapping-pairs in mapping.  If the optional FILE argument is provided, then a single file with that name will be produced and contain all the mappings for all the character sets in MAPPING.  If FILE and INCLUDEDCHARSETS are not provided, then all of the mappings will again go to a single file with a composite name XCCS-csn1,csn2,csn3.TXT.  Each cs may be a single charset number, or a range of adjacent charset numbers.  For example, if the mappings contain entries for characters in charset LATIN, SYMBOLS1, SYMBOLS2, and SYMBOLS3, the file name will be XCCS-0,41-43.TXT.
- 
-If INCLUDEDCHARSETS is provided, it specifies possibly a subset of the mappings in MAPPING for which files should be produced.  This provides an implicit subsetting capability.
-
-Finally, if FILE is not provided and INCLUDEDCHARSETS is T, then a separate file will be produced for each of the character sets, essentially a way of splitting a collection of character-set mappings into separate canonically named files (e.g. XCCS-357=SYMBOLS4.TXT). 
-

lispusers/GITFNS.TEDIT

@@ -1,9 +1,19 @@
-Medley	GITFNS
2
-
4
-
1
-
GITFNS
1
-
4
-
By Ron Kaplan
This document was last edited in February  2023.

GITFNS provides a Medley-oriented interface for comparing the files in two different branches of a git repository.  This makes it easier to understand what functions or other definitions have changed in a Lisp source file, or what text has changed in a Tedit file.  This may be particularly helpful in evaluating the changes in a pull request.
+Medley	GITFNS
+2
+
+4
+
+1
+
+GITFNS
+1
+
+4
+
+By Ron Kaplan
+This document was last edited in February  2023.
+
+GITFNS provides a Medley-oriented interface for comparing the files in two different branches of a git repository.  This makes it easier to understand what functions or other definitions have changed in a Lisp source file, or what text has changed in a Tedit file.  This may be particularly helpful in evaluating the changes in a pull request.
 Separately, GITFNS also provides tools and conventions for bridging between git's file-oriented style of development and version control and Medley's residential development style with its own version control conventions.  GITFNS allows for intelligent comparisons between Lisp source files, Tedit files, and text files in a local git clone and a local Medley-style working directory, and for migrating files to and from the git clone and the working directory.
 
 Git projects:  Connecting git clones to GITFNS capabilities 
@@ -41,29 +51,37 @@ GIT-MAKE-PROJECT will also create a pseudohost {Wprojectname} for the user's wor
 GIT-INIT creates the default set of projects when GITFNS is loaded, as specified in the variable GIT-DEFAULT-PROJECTS, initially containing MEDLEY NOTECARDS LOOPS TEST. GIT-INIT is added to AROUNDEXITFNS so that new pseudohost bindings for the default projects will be created if the sysout or makesys is started on a new machine.
 
 GIT-DEFAULT-PROJECTS     	[Variable]
-Determines the projects that are created (or recreated) by GIT-INIT. This is initialized for the MEDLEY NOTECARDS LOOPS TEST projects, with CLONEPATH=NIL
GITFNS also defines two directory-connecting commands for conveniently connecting to the git and working pseudohosts of a project:
+Determines the projects that are created (or recreated) by GIT-INIT. This is initialized for the MEDLEY NOTECARDS LOOPS TEST projects, with CLONEPATH=NIL
+GITFNS also defines two directory-connecting commands for conveniently connecting to the git and working pseudohosts of a project:
 cdg (projectname) (subdir)    	[Command]
 cdw (projectname) (subdir)    	[Command]
 For example, cdg notecards library  connects to {NOTECARDS}/library/.
 
 Comparing directories and files in different git branches
 In its simplest application, GITFNS is just an off-to-the-side add-on to whatever work practices the user has developed with respect to a locally installed git project.  Its only advantage is to allow for more interpretable git-branch comparisons, especially for pull-request approval. These comparisons are provided by the prc ("pull request compare") Medley executive command:
-prc  (branch)   (DRAFT)  (projectname)	[Command]
This compares the files in branch against the files in the main branch of the project (origin/master or origin/main).  Thus, suppose that a pull request has been issued on github for a particular branch, say branch rmk15 of the default project.  Then
   prc rmk15 
+prc  (branch)   (DRAFT)  (projectname)	[Command]
+This compares the files in branch against the files in the main branch of the project (origin/master or origin/main).  Thus, suppose that a pull request has been issued on github for a particular branch, say branch rmk15 of the default project.  Then
+   prc rmk15 
 brings up a lispusers/COMPAREDIRECTORIES browser for the files that currently differ between origin/rmk15 and origin/master. If the selected files are Lisp source files, the Compare item on the file browser menu will show the differences in a lispusers/COMPARESOURCES browser. The differences for other file types will be shown in a lispusers/COMPARETEXT browser.
 If branch is not specified and the shell command gh is available, then a menu of open pull-request branches will be provided.  If gh is not available, the menu will offer all known branches.  If the optional DRAFT is provided, then the menu will include draft PR's as well as open ones.
 If one PR, say rmk15, contains all the commits of another (rmk14), then the menu will indicate this by
      rmk15 > rmk14
-Note that the prc comparison is  read-only: any comments, approvals, or merges of the branch must be specified using the normal Medley-external git interfaces and commands.
prc is the special case of the more general bbc command ("branch-branch compare") for comparing the files in any two branches:
-bbc  branch1   branch2  (project)	[Command]
This compares the files in branch1 and branch2, for example
+Note that the prc comparison is  read-only: any comments, approvals, or merges of the branch must be specified using the normal Medley-external git interfaces and commands.
+prc is the special case of the more general bbc command ("branch-branch compare") for comparing the files in any two branches:
+bbc  branch1   branch2  (project)	[Command]
+This compares the files in branch1 and branch2, for example
      bbc rmk15 lmm12   (local)
 This will compare the files in origin/rmk15 and origin/lmm12 in the GIT-DEFAULT project.  branch1 defaults to the origin files of the currently checked out branch, the second defaults to origin/master.  If local is non-NIL, then a branch that has neither local/ or origin/ prepended will default to local (e.g. local/rmk15) instead of origin/.  Local refers to the files that are currently in the clone directory, which may not be the same as the origin files, depending on the push/pull status.  
 Either of the branches can be specified with an atom LOCAL, REMOTE, or ORIGIN, in which case bbc will offer menus listing the currently existing branches of that type.
-NOTE: Branch comparison makes use of a git command that has a limit (diff.renameLimit) on the number of files that it can successfully compare.  A message will be printed if that limit is exceeded, asking whether a larger value for that limit should be applied globally.
The command cob ("check out branch") checks out a specified branch:
+NOTE: Branch comparison makes use of a git command that has a limit (diff.renameLimit) on the number of files that it can successfully compare.  A message will be printed if that limit is exceeded, asking whether a larger value for that limit should be applied globally.
+The command cob ("check out branch") checks out a specified branch:
 cob  branch  (next-title-string) (project)	[Command]
 This checks out branch of project and then executes git pull.  The branch parameter may also be a local branch, T (= the current working branch), or NEW/NEXT (= the next working branch).  The current working branch is the branch named <initials>nnn, e.g. rmk15.  The initials are the value of INITIALS as used for SEDIT time stamps, and nnn is the largest of the integers of all of the branches beginning with those initials.
 If branch is NEW or NEXT, then a new initialed branch is created and becomes the user's current branch.  Its number  is one greater than the largest number of previous initialed branches. If next-title-string is provided, then that string will be appended to the name of the branch, after the initials and next number, and two hyphens.  Spaces in next-title-string will also be replaced by hyphens, according to git conventions.
-If branch is not provided, a menu of locally available branches pops up.
The currently checked out branch is obtained by the b? command:
-b?  (project)	[Command]
+If branch is not provided, a menu of locally available branches pops up.
+The currently checked out branch is obtained by the b? command:
+b?  (project)	[Command]
+
 Correlating git source control with separate Medley development
 It is generally unsafe to do Medley development by operating with files in a local clone repository.  Medley provides a residential development environment that integrates tightly with the local file system.  It is important to have consistent access to the source files of the currently running system, especially for files whose contents have been only partially loaded. A git pull or a branch switch that introduces new versions of some files or removes old files altogether can lead to unpredictable disconnects that are hard to recover from.  This is true also because development can go on in the same Medley memory image for days if not weeks, so it is important to have explicit control of any file version changes.
 GITFNS mitigates the danger by conventions that separate the files in the git clone from the files in the working Medley development directory.  The location of the Medley development source tree for a project is given by the WORKINGPATH argument to GIT-MAKE-PROJECT.  If WORKINGPATH is T or NIL and there exists a directory >working-projectname> as a sister to the clone, then that is taken to be the WORKINGPATH and thus the prefix for a pseudohost {Wprojectname}.
@@ -76,13 +94,12 @@ In addition to the commands for comparing and viewing files, the menu for this b
 If the master/main branch is the current branch then the menu has no commands to change the clone directory. The browser will show those files that have been updated from a recent merge, and they can individually be copied from the git branch to realign the two source trees with incremented Medley version numbers.  If the comparison is with a different branch, say the user's current staging branch, copying files from the working Medley to the git clone or deleting git files will set git up for future commits.  
 Note that the menu item for deleting Medley files will cause all versions to be removed, not just the latest one, to avoid the possibility that an earlier one is revealed. Deletion for Medley files is also accomplished by renaming to a {Wprojectname}<deleted> subdirectory so that they can be recovered if a deletion is in error. Files in the git-clone are removed from the file system immediately, since git provides its own recovery mechanism for those files.
 GITFNS does not (yet?) include functions for commits, pushes, or merge for updating the remote repository. Those have to be done outside of Medley through the usual github interfaces, as guided by the information provided by the comparisons.
-(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# 1) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL)))))1
$4
È
$

È
4
È
$

È
1
È
$4
È

$

È
4
È
$

È
4
È

$

È
4
È

$

È
4
È

$

È
4
È


$

È
1
È$1ŠŠ
8$1ŠŠ
8$J
È$

È
PAGEHEADINGRUNNINGHEAD1
È
$	TERMINAL_Q(DEFAULTFONT 1 (TERMINAL 12) (TERMINAL 8) (TERMINAL 8) (POSTSCRIPT (TERMINAL 8)))MODERN
+(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC) STARTINGPAGE# 1) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC)) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY MODERN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT MEDIUM INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC)) (174 36 288 36) NIL) (HEADING NIL (HEADINGTYPE RUNNINGHEAD) (84 744 528 36) NIL) (TEXT NIL NIL (84 96 456 600) NIL)))))1
$4
È
$

È
4
È
$

È
1
È
$4
È

$

È
4
È
$

È
4
È

$

È
4
È

$

È
4
È


$

È
4
È

$

È
1
È$1ŠŠ
8$1ŠŠ
8$J
È$

È
PAGEHEADINGRUNNINGHEAD
+TIMESROMAN$rd(DEFAULTFONT 1 (TERMINAL 12) (TERMINAL 8) (TERMINAL 8) (PDF (TERMINAL 8)) (POSTSCRIPT (TERMINAL 8)))MODERN
 TERMINAL
-MODERNMODERN
-MODERN
-TIMESROMAN$MODERN
-
HRULE.GETFN

HRULE.GETFN

HRULE.GETFN



HRULE.GETFN

HRULE.GETFN
1

RÍé
;¹@
-,




"
	


	&

	



\







+TERMINALMODERNMODERN
+MODERN

HRULE.GETFN

HRULE.GETFN

HRULE.GETFN



HRULE.GETFN

HRULE.GETFN
1

RÍé
;¹
+@	,

"		&

\




 X
-


p

	
6,



	


)

	
)
	

+

	



	

5	

			

@&	

I7
o
E	.8>I
 
Y

€
$
;



}(
)



9


!
0

4



c

	

5

vB	

1OLJ''œ)
2+






Z
!
œ5H
55>

$N
!

M
§‹A@4
-
@Ôâ


k6.	R		<9

	

'Y"(?“

F
<00>ìËò1R
þzº
+
p
	
6,

	
)	)	
+
	


	
5	
			
@&	

I7
o
E	.8>I
 
Y

€
$
;



}(
)


9

!0
4

c
	
5
vB	
1OLJ''œ)2+



Z
!
œ5H
55>
$N
!
M
§‹A@4
+
@Ôâ

k6.	R		<9
	
'Y"(?“
F<00>ìËòDATE:gK(1R
þzº