[net.sources] Window doc #0 of 0-2

chris@umcp-cs.UUCP (07/06/83)

Apparently the windows documentation never made it to most sites, so
I'm sending it split into three parts (with the 'split' program).  One
easy way to make the original is to run the three shell scripts, giving
the files 'xaa', 'xab', and 'xac'; then create the three-line file

	.so xaa
	.so xab
	.so xac

and nroff that.  Or, you can cat the three files together to make
windows.nr.

					- Chris

: Run this shell script with "sh" not "csh"
PATH=:/bin:/usr/bin:/usr/ucb
export PATH
all=FALSE
if [ $1x = -ax ]; then
	all=TRUE
fi
/bin/echo 'Extracting xaa'
sed 's/^X//' <<'//go.sysin dd *' >xaa
X. \" new attempt at stuff to set up tables of contents
X. \" macro to put sections into table of contents
X. \" fails on first section if it is a .uh section
X.de Im
X.In \\$1 
X.ti -\\$2n
X..
X.de In
X'ba \\$1n
X'in \\n($iu + \\n(pou
X..
X.de $0
X.na
X.(x t
X.Tc "\\$1" \\$2 \\$3
X.)x
X.ad b
X..
X.de BI
X.xl -\\$1n
X.IN \\$1n
X..
X.de BO
X.xl +\\$1n
X.IN -\\$1n
X..
X.de Bf			\" *** begin figure macro (arg means floating fig)
X.ie \\n(.$ \
X\{\
X.	(z
X.	nr Ft 1
X.\}
X.el \
X\{\
X.	(b L
X.	nr Ft 0
X.\}
X.hl
X.(c
X..
X.de Ef			\" *** end figure macro
X.)c
X.sp
X.ce 1
XFigure \\n(Fn: \\$1
X.hl
X.ie \\n(Ft=1 .)z
X.el .)b
X.nr Fn +1
X.nr Fb +1
X.Fs
X..
X.nr Fn 1 		\" figure number counter
X.nr Fb 0 		\" figure number counter (the one before)
X.de IN		\" indent the given amount (using base indent)
X.ba \\$1n
X.in \\n($iu + \\n(pou
X..
X.de BI		\" bring both edges in
X.xl -\\$1n
X.IN \\$1n
X..
X.de BO		\" bring both edges out (usuall after a BI)
X.xl +\\$1n
X.IN -\\$1n
X..
X.de AP			\" *** appendix entry
X.bp
X.uh "Appendix \\n(An: \\$1"
X.nr An +1
X..
X.nr An 1
X.\"**********************
X.\"* Declare C function *
X.\"**********************
X.de ff
X.ls 1
X.sp 3
X.ne 6
X.nf
X.in +.5i
X..
X.\"******************
X.\"* End C function *
X.\"******************
X.de fe
X.sp
X.ls 2
X.fi
X.lp
X..
X.de $1
X.sp 3
X..
X.de $2
X.sp 2
X..
X.po 1.0i
X.ll 6.5i
X.tp
X.he ''- % -''
X.sp 0.5i
X.ce 100
XThe Maryland Window Library
X.sp 2
XChris Torek
X.sp 2
XDepartment of Computer Science
XUniversity of Maryland
XCollege Park, MD 20742
X.sp 0.5i
X\fBABSTRACT\fR
X.ce 0
X.BI 0.75i
X.pp
XThere are many applications for windows, but the implementation of
Xwindow software is not an easy task.  The job can be considerably
Xsimplified by eliminating some of the capabilities of a full system,
Xfor example, requiring that windows do not overlap, but this reduces
Xthe usefulness of the result.  This paper describes the University
Xof Maryland Window Library, an implementation that supports a very
Xcomplete character-based window system.
X.BO 0.75i
X.bp
X.ls 2
X.sh 1 "Introduction"
X.pp
XWhat exactly is a window?  It is merely a rectangular region that can
Xdisplay text.  In fact, it is very much like a standard terminal's
Xdisplay.  However, since it exists as a subarea of a real display, it
Xcan be moved around, or covered by other windows.  Windows can never be
Xbigger than the real display.
X.pp
XOne useful analogy for windows is glass over a room full of text.  This
Xroom is called the buffer.  The buffer can be bigger than the window.
XHowever, only the area that can be seen through the window is visible.
X.pp
XTwo separate windows can look into the same room (buffer).  The same
Xroom is revealed through both windows, but not necessarily the same
Xpart of that room.  These windows are called "linked windows" although
X"linked buffers" might have been a better phrase.
X.pp
XThus there are two basic "parts" to a window:  its window descriptor
X(its position and size); and its text buffer or textbuf (holding
Xthe text to be displayed within the window).  It is also useful to have
Xa portion of a window for non-textual information.  This is called the
Xwinbuf, or "window buffer".  Normally the winbuf contains only
X"glass" (empty space), but it can be written on.  For example, an
Xoutline, or frame, may be written onto the glass, to show how much
Xspace is available within the window (see Figure \n(Fn).
X.Bf
X+--------------+
X|              |
X|  Some text   |
X| in a window  |
X|              |
X+--------------+
X.Ef "Framed window"
X.pp
XFigure \n(Fb shows a sixteen by six window with a frame.  (The frame
Xcharacters shown are those used on most displays.  On displays that
Xhave some graphics capability, often the frames are cute little corners
Xand sides that join together, giving the window a very solid
Xappearance.)  The text is in the text buffer, and the frame in the
Xwindow buffer.  This window has a descriptor indicating that the window
Xis sixteen characters across by six characters high, and points to the
Xwindow's winbuf and text buffer.  The text buffer contains two blank
Xlines, the words "Some text" on the third line, the words "in a window"
Xon the fourth line, and two more blank lines.  The winbuf contains the
Xframe characters, with the inside of the winbuf being "glass" that
Xdisplays the text buffer.
X.Bf
X+-------------------+
X|                   |
X|                   |----+
X|                   |    |
X+-------------------+    |
X             |           |
X             +-----------+
X
X.Ef "Overlapping windows"
X.pp
XWindows can overlap.  In Figure \n(Fb two windows overlap.  The only
Xdifference between overlapped characters and non-overlapped characters
Xis that overlapped characters are invisible.  If a window is covered,
Xit can be brought to the "front" (where it will cover whatever used to
Xcover it).  Windows may also be hidden to make them totally invisible.
XHiding a window that covers others will expose the others:  hiding the
Xupper window in Figure \n(Fb would make the lower one completely
Xvisible.  Hiding a window has no effect on the operations that can be
Xperformed on it; one can't see the results, however, until the window
Xis unhidden.
X.pp
XIn addition to windows, there is a single "box" that may be turned on.
XIt is a hollow rectangular region on the display that is made of
Xinverse video characters.  It can be used either to outline a window,
Xor as a roving block cursor.  As a window outline, the box can be used
Xto display where a window may be created or moved.  As a cursor, the
Xbox can be used with a mouse or a bitpad as a pointer for selecting
Xwindows.
X.sh 1 "What's in a window?"
X.sh 2 "Cursors"
X.pp
XLike a terminal, a window needs a cursor.  The window's cursor shows
Xwhere the next character will be placed within that window, though
Xcharacters are actually written into the text buffer.  The cursor is
Xnormally visible as a blinking block.  It can be turned off if desired.
X.pp
XSince the window actually has two pieces, the winbuf and the textbuf,
Xit also has more than one cursor.  The normal cursor ("window cursor")
Xis the one just described.  There are two others:  the aux cursor and
Xthe buffer cursor.  The aux cursor and the buffer cursor will be
Xdiscussed later; for now it is enough to say that they are never
Xvisible, and that all three cursors are mutually independent.  In this
Xdocument, "the cursor" refers to the window cursor.
X.sh 2 "Text"
X.pp
XCharacters within a window can be in any combination of four modes:
Xbold, underscored, blinking, and reverse video.  There is a "current
Xmode" associated with each window.  This is the mode with which future
Xcharacters will be printed.  In addition, there is the "glass factor"
Xfor characters within the winbuf:  are they real characters, or are
Xthey just empty slots through which the text buffer should be
Xdisplayed?  Frame characters are not glassy; the rest of the winbuf is
Xnormally filled with glassy blanks.  The only way to put things into
Xthe winbuf is with the aux cursor or one of the special functions,
Xe.g., frame window.
X.sh 2 "Text Buffers vs. Window Buffers"
X.pp
XA window buffer, as stated earlier, is normally just "glass" through
Xwhich the text buffer is displayed.  However, it is possible to write
Xcharacters, such as those making up a frame, into the winbuf.  These
Xcharacters then obscure some of the characters in the text buffer.  It
Xis also possible to write modes into the winbuf.  These modes can be
Xconsidered "tinted glass":  they affect the display of characters being
Xviewed, though the characters themselves are not changed.  For example,
Xif inverse video has been "painted" onto the "glass", all the
Xcharacters in the text buffer under that paint are displayed in inverse
Xvideo.  If the glass is wiped clean of its inverse video paint, the
Xcharacters will be restored to normal.  The modes on the glass are
Xexclusive or'ed with those in the text buffer.
X.pp
XText buffers also have cursors, namely the "buffer cursor".  In linked
Xwindows, where two window descriptors share a text buffer, there is
Xonly one buffer cursor.  In other words, the buffer cursor is shared
Xalong with the text buffer.
X.sh 3 "Margin Settings and the Aux Cursor"
X.pp
XWindow buffers also have margin settings.  These are mainly used
Xinternally to keep the window cursor from overwriting the frames (if
Xthere are any), but can be set if desired.  Margins determine the
Xamount of glass in the winbuf.  Anything outside the margins is
Xstrictly off-limits; the space inside the margins is the glass.
XHowever, unwritable margins would not be particularly useful.  The aux
Xcursor is permitted to roam over the entire winbuf.  It can be used to
Xprint characters directly into the winbuf.  Any character in the winbuf
Xwill take precedence over the character underneath it in the text
Xbuffer.  Essentially, the aux cursor writes on the glass.
X.pp
XWhile the aux cursor can be used to write into the winbuf, it can also
Xbe used in a sneaky way to "un-write" characters:  the aux cursor is
Xpermitted to erase from the glass.  Erasing a character from the winbuf
Xre-exposes the character underneath in the text buffer.  Tinted glass
Xis created by erasing with a mode other than normal (i.e.  any
Xcombination of blinking, bold, underscored, and reverse video).
X.pp
XText buffers do not have margin settings.  No part of the text buffer
Xis protected.  Quite often, however, some of the text buffer is not
Xvisible.  In a typical framed window, the entire top and bottom lines
Xof the buffer, and the left and right edges, are not visible, since
Xthey are covered by the frame characters.  (Note that since the aux
Xcursor could at any time erase part of the frames, they must remain
Xinvisible until explicitly exposed.  They can't be automatically "moved
Xdown and right".)  Figure \n(Fn should clear some of the mud.
X.Bf
X.)c
X.ce
XA window
X.sp
X.(c
X+------------------+
X|his is the second |
X|ne, third line, fo|
X|th line,...       |
X+------------------+
X.)c
X.sp
X.ce
Xand its text buffer
X.sp
X.(c
XXXXXXXXXXXXXXXXXXXXX
XThis is the second l
Xine, third line, fou
Xrth line,...       Y
XZZZZZZZZZZZZZZZZZZZZ
X.Ef "A window and buffer"
X.sh 3 "Operations"
X.pp
XSince a buffer can be larger than its window, there are "buffer
Xoperations" and "window operations".  In general, window operations
Xdeal with the visible portion of the text buffer, and in many cases
Xwith the glass through which said text is viewed.  Buffer operations
Xdeal exclusively with the text buffer, and are not limited to the
Xvisible portions\**.
X.(f
X\**"Visible portions" can include covered or hidden portions.
X"Covered" is used to describe windows or characters that are obscured
Xby other windows.  "Hidden" is used to describe windows not displayed
Xat all by specific request.  The visible portion of a window's textbuf
Xis the area that is inside the window's margins; this is irrespective
Xof whether the window is hidden and/or covered.
X.)f
XFigure \n(Fn shows what happens when a line delete is performed as both
Xa window operation and a buffer operation on a window that is smaller
Xthan its buffer.
X.Bf
X  Window        Buffer        Window        Buffer
X
X +------+     0123456789     +------+     0123456789
X |CDEFGH|     ABCDEFGHIJ     |CDEFGH|     ABCDEFGHIJ
X |MNOPQR|     KLMNOPQRST     |MNOPQR|     KLMNOPQRST
X |WXYZab|     UVWXYZabcd     |WXYZab|     UVWXYZabcd
X +------+     efghijklmn     +------+     efghijklmn
X
X(delete line from window)   (delete line from buffer)
X
X +------+     0123456789     +------+     0123456789
X |CDEFGH|     ABCDEFGHIJ     |CDEFGH|     ABCDEFGHIJ
X |WXYZab|     KLWXYZabST     |WXYZab|     UVWXYZabcd
X |      |     UV      cd     |ghijkl|     efghijklmn
X +------+     efghijklmn     +------+
X.Ef "Window and Buffer Operations: Line Delete"
X.pp
XWhen the cursor position is relevant to the operation, window
Xoperations are done at the window cursor, and buffer operations at the
Xbuffer cursor.  Only two operations (aux print and aux read) are done
Xat the aux cursor position.
X.sh 2 "Scrolling"
X.pp
XThe real reason for having separate text buffers and window buffers is
Xto allow the storage of more text than is visible.  That is, buffers
Xcan be much larger than the window through which they are viewed.  This
Xmeans that a window can be moved over the buffer.  To go back to the
Xroom-of-text analogy, the wall is flexible, and the glass of the window
Xcan be pulled around on it.  In the window library, moving the window
Xover its text buffer is called scrolling.  Thus you can scroll a window
Xup, down, left, or right, over its buffer.  There are limits, however:
Xthe amount of scrolling permitted depends on just how much more space
Xthere is in the buffer than the window.  You can't pull the glass past
Xthe edge of the wall.
X.pp
XThe more conventional definition of scrolling is moving the existing
Xtext upward or downward, discarding one line at the top or bottom, and
Xmaking room for new text.  The window library provides this by making
Xan exception to the scrolling limits.  If the window is scrolled past
Xthe end of the buffer, the buffer is "extended" one line at the bottom,
Xand a line is "erased" from the top, making the window fit once again.
X(The actual algorithm is to copy the text upward, keeping the window at
Xthe bottom of the buffer.)  A similar exception is made for scrolling
Xpast the beginning of the buffer.  This action (moving the text upwards
Xor downwards, losing a line off the top or bottom) is called "scrolling
Xthe buffer", and may be done directly, without moving the window past
Xthe edge of the buffer.
X.pp
XWindows automatically scroll when necessary.  When this happens, the
Xnumber of lines scrolled is controlled by the window's "popup".  Popup
Xdefaults to one, but can be set anywhere from zero to the size of the
Xwindow.  Scrolling by \fIn\fR lines (\fIn\fR > 1) is exactly equivalent to
Xscrolling by one line \fIn\fR times.  Scrolling by zero lines is a special
Xcase.  It is not scrolling at all.  Rather, the cursor is brought to
Xthe top of the window and the top line is cleared.  Each time the
Xcursor advances to the next line, that line is also cleared.  When the
Xcursor reaches the bottom of the window, the process is repeated.  This
Xis much faster on some terminals, but tends to be confusing.
X.sh 2 "Printing Text"
X.pp
XThere are three ways to print text into a window.  The first is to
Xprint at the window cursor, the second to print at the buffer cursor,
Xand the third to print at the aux cursor.  The first and second are
Xgenerally more useful than the third, and have less "drastic" effects.
X.pp
XThe aux cursor can be anywhere within the window buffer, and characters
Xprinted with it are required to have a mode.  This mode includes (in
Xaddition to the standard four mode bits) the "glassiness" information.
XThe character being printed is not interpreted in any way, but simply
Xshoved onto the glass.  If the character is not standard ASCII (codes
X32 to 126 decimal), the results are terminal-dependent.  Some terminals
Xuse special codes for the window frame characters, and look for such
Xcodes; others do not and may end up clearing the screen, repositioning
Xthe cursor, or doing other undesirable things.  Therefore, the aux
Xcursor must be used very carefully.
X.pp
XBoth the window cursor and the buffer cursor check the character being
Xprinted, and take special actions for non-ASCII characters.  Most of
Xthese codes are ignored.  The following are not:
X.ip \fBBELL\fR
XASCII 7, or bell, rings the terminal's bell.  If desired, this may be
Xset to flash the terminal's screen instead, providing that the terminal
Xhas this capability.  Visible bells are often nicer in a crowded
Xworking environment.
X.ip \fBBS\fR
XASCII 8, or backspace, moves the cursor backwards one character.  If
Xthe cursor is at its leftmost permitted column, it does not move.
X.ip \fBTAB\fR
XASCII 9, tab, moves the cursor forward one tab stop.  Tab stops are
Xset at every eight columns.  If there are no remaining tab stops, the
Xcursor is moved to the rightmost column.
X.ip \fBLF\fR
XASCII 10, linefeed, moves the cursor down one line without changing its
Xcolumn.  (If CR/LF mapping is turned on, it moves it to the leftmost
Xcolumn.)  If the cursor is on the bottom line, the window is scrolled.
XIf this is the buffer cursor, then one line at the top of the buffer is
Xthrown away, and a new blank\** line is introduced (i.e. the buffer is
Xscrolled).
X.(f
X\**The blanks introduced are in the current mode of the window; i.e.
Xif the current mode is inverse video, a line of inverse video blanks is
Xmade.  This is true for all functions that introduce blanks in the
Xbuffer.
X.)f
XIf this is the window cursor, then the window is scrolled by its popup.
X.ip \fBCR\fR
XASCII 13, carriage return, moves the cursor to the leftmost column.
X(If CR/LF mapping is turned on, it also performs a linefeed).
X.pp
XFor the window and buffer cursors, autowrap and CR/LF mapping can be
Xturned on and off.  Autowrap means that when a character is written in
Xthe last column of the window or buffer, it is wrapped to the next
Xline, as if a carriage return and line feed had been printed.  This
Xmode defaults on.  CR/LF mapping makes both carriage return and line
Xfeed go to the first column of the next line; i.e., either code
Xperforms the actions normally done by both.  This mode defaults off.
XThe aux cursor always wraps, and, upon reaching the last column of the
Xlast line, wraps to the first column of the first line.  Since it does
Xnot translate special codes, it ignores CR/LF mapping.  It should not
Xnormally be used to print CRs or LFs.
X.sh 1 "Update Optimization"
X.pp
XThe Maryland Window Library keeps track of what the terminal's screen
Xlooks like, and when asked to update ("refresh") the screen, attempts
Xto do it with the greatest possible speed.  If a section of lines on
Xthe current screen matches a section on the desired screen, line insert
Xand delete operations may be done to move the old lines to their new
Xposition.  If subsections of an old line match those of a new one,
Xinsert and delete character may be used.  Any number of arbitrarily
Xcomplex operations may be done between screen refreshes; the update is
Xcomputed at refresh time.
X.sh 1 "Signal Handling"
X.pp
XSince window display mode turns on many special Unix\**
X.(f
X\**Unix is a trademark of Bell Laboratories.
X.)f
Xtty modes, it needs to take special consideration of signals that
Xnormally cause it to stop or exit.  (For more information on signals,
Xsee \fIsignal\fR(2) and \fIjobs\fR(3j) in the Unix Programmer's Manual
X[Joy et al 81].)
XThe Maryland Window Library uses the job control routines provided in
XBerkeley 4.1 Unix.  Since many Unix systems don't have job control, the
Xactual calls to these routines are made only if permitted by the
Xprogrammer.  If signal handling is not enabled, it is the programmer's
Xjob to manage the Unix signals.  Signal management is not always easy,
Xso if enabled, the window library will provide default signal handlers
Xfor those signals likely to occur, namely SIGINT and SIGTSTP.
XSIGINT is the interrupt signal (generated with the DEL key).  The
Xdefault handler for this signal exits after restoring the initial
Xterminal modes.  SIGTSTP is the terminal stop signal (generated with
Xcontrol-Z).  The default handler for this signal cleans up the terminal
Xsettings, suspends the process, and upon resumption re-initializes the
Xterminal to windows mode.\**
X.(f
X\**I chose not to catch SIGQUIT since core dumps are handy for
Xdebugging.  Besides, one can always call \fBsigset (SIGQUIT, Wexit);\fR.
X.)f
X.pp
XEnabling signal handling is done with the \fBWinit\fR call (described
Xlater).  If at all possible, it is recommended that signal handling be
Xenabled.  If the default signal handlers are not desired, signal
Xhandling should be enabled anyway, and the handlers changed to new
Xfunctions via \fBsigset\fR.
X.pp
XIf the target operating system does not have the jobs library, then
Xthere are two alternatives.  One is to write a jobs library simulator
X(see Appendix 3);
Xthe other to not use it.  In either case the functions \fBsigset\fR,
X\fBsighold\fR, \fBsigrelse\fR, and \fBsigignore\fR must be provided.
XIf the functions are not being used, they may
Xbe empty (e.g.  \fBsigset () {}\fR).
X.sh 1 "Window Library Functions"
X.pp
XThis section describes the actual functions provided by the Maryland
XWindow Library.  All return a value.  Most return zero if they succeed;
Xexceptions are listed.  To compile with the library, #include the file
X<local/window.h>, and include "\-lwinlib \-ljobs \-ltermlib" when making
Xthe executable.  (See Appendix 4 for sample programs.)  The first four
Xfunctions listed are those for initializing, suspending, and cleaning
Xup; the remainder are in alphabetical order.  Note:  several functions
X"clip" their values.  This means that if they are given out-of-range
Xvalues, the nearest value that is in range is used.
X.pp
XThe window library provides several types, macros, and variables.  The
Xmain type is \fBWin\fR, and is the window descriptor structure.  There is
Xalso a "current" window, called \fBCurWin\fR, but it is in no way special;
Xit is provided for convenience only.  It is affected only by the
Xfunctions \fBWopen\fR, \fBWlink\fR, \fBWclose\fR, \fBWcloseall\fR, \fBWfind\fR, and
X\fBWboxfind\fR.  The type, macro, and variable definitions are listed in
XAppendix 1.  Note:  \fBbold\fR text indicates exact strings.  \fIUnderscored\fR
Xtext indicates arguments that are to be filled in.
X.ff
X\fBWinit (\fIsettings\fB,\fR \fInomagic\fB)
Xstruct sgttyb *\fIsettings\fB;
Xint\fR \fInomagic\fB;\fR
X.fe
XInitializes the window system, clearing the screen and setting the tty
Xmodes.  Normally, both \fIsettings\fR and \fInomagic\fR should be given as
Xzero.  To resume a suspended session, where \fBWinit\fR has already been
Xcalled, \fIsettings\fR may be given as \fB(struct sgttyb *) 1\fR.  If special
Xtty mode settings are desired, \fIsettings\fR can be the address of a
Xpreset \fBstruct sgttyb\fR structure (see \fIstty\fR(2), \fIgtty\fR(2)).  (Baud
Xrate will be replaced with the actual baud rate of the terminal.)
XUnless signal handling is not desired (or not necessary, e.g. in raw
Xmode) \fInomagic\fR should be given as zero.  Otherwise signal handling
Xwill not be enabled.  A value of zero will set \fBWsuspend\fR to catch
XSIGTSTP and \fBWexit\fR to handle SIGINT.
X.pp
X\fBWinit\fR returns zero if the window package can be run on the terminal.
XIf \fBWinit\fR does not return zero, nothing has been done, and none of the
Xother functions should be called.  (\fBWinit\fR will return the same value
Xif called again, so if it said "Ok" once it won't change its mind.)
X.ff
X\fBWsuspend ()\fR
X.fe
XSuspends the process by calling \fBWcleanup\fR, sending SIGTSTP, and then
Xcalling \fBWinit (1, 1)\fR.  This is the standard way to handle control-Z.
X.ff
X\fBWcleanup ()\fR
X.fe
XCleans up the terminal settings to the way they were when \fBWinit\fR was
Xcalled.  This must be done before exiting, or before giving up control
Xof the terminal (e.g. to a subshell).
X.ff
X\fBWexit (\fIcode\fB)
Xint\fR \fIcode\fB;\fR
X.fe
XCalls \fBWcleanup\fR and \fBexit (\fIcode\fB)\fR.  This should be used instead of
X\fBexit\fR unless \fBWcleanup\fR has already been called.
X.ff
X\fBDing ()\fR
X.fe
XRings the terminal's bell.  This is normally just called when control-G
X(bell) is printed, but it can be called directly if desired.  If the
Xvariable \fBVisibleBell\fR is nonzero, and the terminal supports it, this
Xwill flash the terminal's screen instead.
X.ff
X\fBMax (\fIa\fB,\fR \fIb\fB)\fR
X.fe
XThis is a macro which expands to
X.sp
X\fB((\fIa\fB) > (\fIb\fB) ? (\fIa\fB) : (\fIb\fB))\fR
X.sp
Xwhich is the larger of the two arguments.
X.ff
X\fBMin (\fIa\fB,\fR \fIb\fB)\fR
X.fe
XThis is a macro which expands to
X.sp
X\fB((\fIa\fB) < (\fIb\fB) ? (\fIa\fB) : (\fIb\fB))\fR
X.sp
Xwhich is the smaller of the two arguments.
X.ff
X\fBWAcursor (\fIw\fB,\fR \fIrow\fB,\fR \fIcol\fB)
XWin *\fIw\fB;
Xint\fR \fIrow\fB,\fR \fIcol\fB;\fR
X.fe
XSets the position of the window cursor.  The position (0, 0) is as far
Xleft and up as the window cursor can get over the text buffer; this
Xfunction may scroll the window to get to the specified position.  The
Xname of this function stands for "Window Absolute cursor move", meaning
Xmove the window cursor to an absolute coordinate, where "absolute"
Xmeans measured from as far left and up as possible.  To move only
Xwithin the window (where (0, 0) is the upper left corner inside the
Xmargin settings), use \fBWWcursor\fR.  \fIRow\fR and \fIcol\fR are clipped to be
Xwithin the window.
X.ff
X\fBWAread (\fIw\fB,\fR \fIcharonly\fB)
XWin *\fIw\fB;
Xint\fR \fIcharonly\fB;\fR
X.fe
XReads back a character and (unless \fIcharonly\fR is set) its mode from
Xwindow \fIw\fR's winbuf at the aux cursor.  The aux cursor is then
Xadvanced, wrapping from the last character of the last line to the
Xfirst character of the first line if necessary.  See \fBWCHAROF\fR and
X\fBWMODEOF\fR.
X.ff
X\fBWBclear (\fIw\fB,\fR \fIhowto\fB)
XWin *\fIw\fB;
Xint\fR \fIhowto\fB;\fR
X.fe
XClears (sets to blanks) the text buffer attached to window \fIw\fR.  If
X\fIhowto\fR is zero, the buffer is cleared from the buffer cursor to the
Xend of the buffer, including the character under the cursor; if one,
Xfrom the beginning of the buffer to the cursor, not including the
Xcharacter under the cursor; if two, the entire buffer is cleared.
XOther values are treated as zero.
X.ff
X\fBWBclearline (\fIw\fB,\fR \fIhowto\fB)
XWin *\fIw\fB;
Xint\fR \fIhowto\fB;\fR
X.fe
XClears the line the cursor is on in the text buffer attached to window
X\fIw\fR.  If \fIhowto\fR is zero the line is cleared from the buffer cursor to
Xthe end of the line, including the character under the cursor; if one,
Xfrom the beginning of the line to the buffer cursor, not including the
Xcharacter under the cursor; if two, the entire line is cleared.  Other
Xvalues are treated as zero.
X.ff
X\fBWBcursor (\fIw\fB,\fR \fIrow\fB,\fR \fIcol\fB)
XWin *\fIw\fB;
Xint\fR \fIrow\fB,\fR \fIcol\fB;\fR
X.fe
XSets the buffer cursor of the text buffer attached to window \fIw\fR to row
X\fIrow\fR, column \fIcol\fR.  Note:  there is only one buffer cursor per buffer
X(i.e.  two linked windows have only one buffer cursor).  \fIRow\fR and
X\fIcol\fR are clipped to be within the buffer.
X.ff
X\fBWBdelchars (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\fB;
Xint\fR \fIn\fB;\fR
X.fe
XDeletes \fIn\fR characters starting at the buffer cursor from the text
Xbuffer attached to window \fIw\fR.
X.ff
X\fBWBdelcols (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\fB;
Xint\fR \fIn\fB;\fR
X.fe
XDeletes \fIn\fR columns starting at the buffer cursor column from the text
Xbuffer attached to window \fIw\fR.  In effect, calls \fBWBdelchars\fR on each
Xline.
X.ff
X\fBWBdellines (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\fB;
Xint\fR \fIn\fB;\fR
X.fe
XDeletes \fIn\fR lines from the text buffer attached to window \fIw\fR, starting
Xwith the line containing the buffer cursor.
X.ff
X\fBWBinschars (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\fB;
Xint\fR \fIn\fB;\fR
X.fe
XInserts \fIn\fR blanks at the buffer cursor in the text buffer attached to
Xwindow \fIw\fR.
X.ff
X\fBWBinscols (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\B;
Xint\fR \fIn\fB;\fR
X.fe
XInserts \fIn\fR columns in the text buffer attached to window \fIw\fR.  In
Xeffect, calls \fBWBinschars\fR on each line.
X.ff
X\fBWBinslines (\fIw\fB,\fR \fIn\fB)
XWin *\fIw\fB;
Xint\fR \fIn\fB;\fR
X.fe
XInserts \fIn\fR lines at the buffer cursor in the text buffer attached to
Xwindow \fIw\fR.
X.ff
X\fBWBputc (\fIc\fB,\fR \fIw\fB)\fR\**
X.(f
X\**Note that for this and all other \fBputc\fR and \fBputs\fR functions, the
Xwindow parameter comes \fIlast\fR.
X.)f
X\fBchar\fR \fIc\fB;
XWin *\fIw\fB;\fR
X.fe
XPrints character \fIc\fR to the buffer attached to window \fIw\fR at the buffer
Xcursor, and advances the buffer cursor.  Note that this character may
Xwell not be visible inside any or all of the windows using this buffer;
Xcare should be taken when using this function to be sure that (if
Xnecessary and desired) a window is \fBWrelscroll\fRed so that the character
Xis visible.
X.ff
X\fBWBputs (\fIs\fB,\fR \fIw\fB)
Xchar *\fIs\fB;
XWin *\fIw\fB;\fR
X.fe
XPuts a C style (null terminated) string into the buffer attached to
Xwindow \fIw\fR, by using \fBWBputc\fR on each character in \fIs\fR.
X.ff
X\fBWBread (\fIw\fB,\fR \fIcharonly\fB)
XWin *\fIw\fB;
Xint\fR \fIcharonly\fB;\fR
X.fe
XReads back a character and (unless \fIcharonly\fR is set) its mode from the
Xbuffer attached to window \fIw\fR at the buffer cursor.  The buffer cursor
Xis then advanced, wrapping from the last character of the last line to
Xthe first character of the first line if necessary.  (Note that this
Xignores the autowrap setting.)  See \fBWCHAROF\fR and \fBWMODEOF\fR.
//go.sysin dd *
made=TRUE
if [ $made = TRUE ]; then
	/bin/chmod 644 xaa
	/bin/echo -n '	'; /bin/ls -ld xaa
fi
-- 
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs
ARPA:	chris.umcp-cs@UDel-Relay