diff options
Diffstat (limited to 'scratch/bash-3.1-postpatch/lib/termcap/grot/termcap.info-2')
| -rw-r--r-- | scratch/bash-3.1-postpatch/lib/termcap/grot/termcap.info-2 | 974 |
1 files changed, 974 insertions, 0 deletions
diff --git a/scratch/bash-3.1-postpatch/lib/termcap/grot/termcap.info-2 b/scratch/bash-3.1-postpatch/lib/termcap/grot/termcap.info-2 new file mode 100644 index 0000000..6098d62 --- /dev/null +++ b/scratch/bash-3.1-postpatch/lib/termcap/grot/termcap.info-2 @@ -0,0 +1,974 @@ +This is Info file ./termcap.info, produced by Makeinfo-1.55 from the +input file ./termcap.texi. + + This file documents the termcap library of the GNU system. + + Copyright (C) 1988 Free Software Foundation, Inc. + + Permission is granted to make and distribute verbatim copies of this +manual provided the copyright notice and this permission notice are +preserved on all copies. + + Permission is granted to copy and distribute modified versions of +this manual under the conditions for verbatim copying, provided that +the entire resulting derived work is distributed under the terms of a +permission notice identical to this one. + + Permission is granted to copy and distribute translations of this +manual into another language, under the above conditions for modified +versions, except that this permission notice may be stated in a +translation approved by the Foundation. + + +File: termcap.info, Node: Naming, Next: Inheriting, Prev: Capability Format, Up: Data Base + +Terminal Type Name Conventions +============================== + + There are conventions for choosing names of terminal types. For one +thing, all letters should be in lower case. The terminal type for a +terminal in its most usual or most fundamental mode of operation should +not have a hyphen in it. + + If the same terminal has other modes of operation which require +different terminal descriptions, these variant descriptions are given +names made by adding suffixes with hyphens. Such alternate descriptions +are used for two reasons: + + * When the terminal has a switch that changes its behavior. Since + the computer cannot tell how the switch is set, the user must tell + the computer by choosing the appropriate terminal type name. + + For example, the VT-100 has a setup flag that controls whether the + cursor wraps at the right margin. If this flag is set to "wrap", + you must use the terminal type `vt100-am'. Otherwise you must use + `vt100-nam'. Plain `vt100' is defined as a synonym for either + `vt100-am' or `vt100-nam' depending on the preferences of the + local site. + + The standard suffix `-am' stands for "automatic margins". + + * To give the user a choice in how to use the terminal. This is done + when the terminal has a switch that the computer normally controls. + + For example, the Ann Arbor Ambassador can be configured with many + screen sizes ranging from 20 to 60 lines. Fewer lines make bigger + characters but more lines let you see more of what you are editing. + As a result, users have different preferences. Therefore, termcap + provides terminal types for many screen sizes. If you choose type + `aaa-30', the terminal will be configured to use 30 lines; if you + choose `aaa-48', 48 lines will be used, and so on. + + Here is a list of standard suffixes and their conventional meanings: + +`-w' + Short for "wide". This is a mode that gives the terminal more + columns than usual. This is normally a user option. + +`-am' + "Automatic margins". This is an alternate description for use when + the terminal's margin-wrap switch is on; it contains the `am' + flag. The implication is that normally the switch is off and the + usual description for the terminal says that the switch is off. + +`-nam' + "No automatic margins". The opposite of `-am', this names an + alternative description which lacks the `am' flag. This implies + that the terminal is normally operated with the margin-wrap switch + turned on, and the normal description of the terminal says so. + +`-na' + "No arrows". This terminal description initializes the terminal to + keep its arrow keys in local mode. This is a user option. + +`-rv' + "Reverse video". This terminal description causes text output for + normal video to appear as reverse, and text output for reverse + video to come out as normal. Often this description differs from + the usual one by interchanging the two strings which turn reverse + video on and off. + + This is a user option; you can choose either the "reverse video" + variant terminal type or the normal terminal type, and termcap will + obey. + +`-s' + "Status". Says to enable use of a status line which ordinary + output does not touch (*note Status Line::.). + + Some terminals have a special line that is used only as a status + line. For these terminals, there is no need for an `-s' variant; + the status line commands should be defined by default. On other + terminals, enabling a status line means removing one screen line + from ordinary use and reducing the effective screen height. For + these terminals, the user can choose the `-s' variant type to + request use of a status line. + +`-NLINES' + Says to operate with NLINES lines on the screen, for terminals + such as the Ambassador which provide this as an option. Normally + this is a user option; by choosing the terminal type, you control + how many lines termcap will use. + +`-NPAGESp' + Says that the terminal has NPAGES pages worth of screen memory, + for terminals where this is a hardware option. + +`-unk' + Says that description is not for direct use, but only for + reference in `tc' capabilities. Such a description is a kind of + subroutine, because it describes the common characteristics of + several variant descriptions that would use other suffixes in + place of `-unk'. + + +File: termcap.info, Node: Inheriting, Next: Changing, Prev: Naming, Up: Data Base + +Inheriting from Related Descriptions +==================================== + + When two terminal descriptions are similar, their identical parts do +not need to be given twice. Instead, one of the two can be defined in +terms of the other, using the `tc' capability. We say that one +description "refers to" the other, or "inherits from" the other. + + The `tc' capability must be the last one in the terminal description, +and its value is a string which is the name of another terminal type +which is referred to. For example, + + N9|aaa|ambassador|aaa-30|ann arbor ambassador/30 lines:\ + :ti=\E[2J\E[30;0;0;30p:\ + :te=\E[60;0;0;30p\E[30;1H\E[J:\ + :li#30:tc=aaa-unk: + +defines the terminal type `aaa-30' (also known as plain `aaa') in terms +of `aaa-unk', which defines everything about the Ambassador that is +independent of screen height. The types `aaa-36', `aaa-48' and so on +for other screen heights are likewise defined to inherit from `aaa-unk'. + + The capabilities overridden by `aaa-30' include `li', which says how +many lines there are, and `ti' and `te', which configure the terminal +to use that many lines. + + The effective terminal description for type `aaa' consists of the +text shown above followed by the text of the description of `aaa-unk'. +The `tc' capability is handled automatically by `tgetent', which finds +the description thus referenced and combines the two descriptions +(*note Find::.). Therefore, only the implementor of the terminal +descriptions needs to think about using `tc'. Users and application +programmers do not need to be concerned with it. + + Since the reference terminal description is used last, capabilities +specified in the referring description override any specifications of +the same capabilities in the reference description. + + The referring description can cancel out a capability without +specifying any new value for it by means of a special trick. Write the +capability in the referring description, with the character `@' after +the capability name, as follows: + + NZ|aaa-30-nam|ann arbor ambassador/30 lines/no automatic-margins:\ + :am@:tc=aaa-30: + + +File: termcap.info, Node: Changing, Prev: Inheriting, Up: Data Base + +When Changes in the Data Base Take Effect +========================================= + + Each application program must read the terminal description from the +data base, so a change in the data base is effective for all jobs +started after the change is made. + + The change will usually have no effect on a job that have been in +existence since before the change. The program probably read the +terminal description once, when it was started, and is continuing to +use what it read then. If the program does not have a feature for +reexamining the data base, then you will need to run it again (probably +killing the old job). + + If the description in use is coming from the `TERMCAP' environment +variable, then the data base file is effectively overridden, and +changes in it will have no effect until you change the `TERMCAP' +variable as well. For example, some users' `.login' files +automatically copy the terminal description into `TERMCAP' to speed +startup of applications. If you have done this, you will need to +change the `TERMCAP' variable to make the changed data base take effect. + + +File: termcap.info, Node: Capabilities, Next: Summary, Prev: Data Base, Up: Top + +Definitions of the Terminal Capabilities +**************************************** + + This section is divided into many subsections, each for one aspect of +use of display terminals. For writing a display program, you usually +need only check the subsections for the operations you want to use. +For writing a terminal description, you must read each subsection and +fill in the capabilities described there. + + String capabilities that are display commands may require numeric +parameters (*note Parameters::.). Most such capabilities do not use +parameters. When a capability requires parameters, this is explicitly +stated at the beginning of its definition. In simple cases, the first +or second sentence of the definition mentions all the parameters, in +the order they should be given, using a name in upper case for each +one. For example, the `rp' capability is a command that requires two +parameters; its definition begins as follows: + + String of commands to output a graphic character C, repeated N + times. + + In complex cases or when there are many parameters, they are +described explicitly. + + When a capability is described as obsolete, this means that programs +should not be written to look for it, but terminal descriptions should +still be written to provide it. + + When a capability is described as very obsolete, this means that it +should be omitted from terminal descriptions as well. + +* Menu: + +* Basic:: Basic characteristics. +* Screen Size:: Screen size, and what happens when it changes. +* Cursor Motion:: Various ways to move the cursor. +* Wrapping:: What happens if you write a character in the last column. +* Scrolling:: Pushing text up and down on the screen. +* Windows:: Limiting the part of the window that output affects. +* Clearing:: Erasing one or many lines. +* Insdel Line:: Making new blank lines in mid-screen; deleting lines. +* Insdel Char:: Inserting and deleting characters within a line. +* Standout:: Highlighting some of the text. +* Underlining:: Underlining some of the text. +* Cursor Visibility:: Making the cursor more or less easy to spot. +* Bell:: Attracts user's attention; not localized on the screen. +* Keypad:: Recognizing when function keys or arrows are typed. +* Meta Key:: META acts like an extra shift key. +* Initialization:: Commands used to initialize or reset the terminal. +* Pad Specs:: Info for the kernel on how much padding is needed. +* Status Line:: A status line displays "background" information. +* Half-Line:: Moving by half-lines, for superscripts and subscripts. +* Printer:: Controlling auxiliary printers of display terminals. + + +File: termcap.info, Node: Basic, Next: Screen Size, Up: Capabilities + +Basic Characteristics +===================== + + This section documents the capabilities that describe the basic and +nature of the terminal, and also those that are relevant to the output +of graphic characters. + +`os' + Flag whose presence means that the terminal can overstrike. This + means that outputting a graphic character does not erase whatever + was present in the same character position before. The terminals + that can overstrike include printing terminals, storage tubes (all + obsolete nowadays), and many bit-map displays. + +`eo' + Flag whose presence means that outputting a space erases a + character position even if the terminal supports overstriking. If + this flag is not present and overstriking is supported, output of + a space has no effect except to move the cursor. + + (On terminals that do not support overstriking, you can always + assume that outputting a space at a position erases whatever + character was previously displayed there.) + +`gn' + Flag whose presence means that this terminal type is a generic type + which does not really describe any particular terminal. Generic + types are intended for use as the default type assigned when the + user connects to the system, with the intention that the user + should specify what type he really has. One example of a generic + type is the type `network'. + + Since the generic type cannot say how to do anything interesting + with the terminal, termcap-using programs will always find that the + terminal is too weak to be supported if the user has failed to + specify a real terminal type in place of the generic one. The + `gn' flag directs these programs to use a different error message: + "You have not specified your real terminal type", rather than + "Your terminal is not powerful enough to be used". + +`hc' + Flag whose presence means this is a hardcopy terminal. + +`rp' + String of commands to output a graphic character C, repeated N + times. The first parameter value is the ASCII code for the desired + character, and the second parameter is the number of times to + repeat the character. Often this command requires padding + proportional to the number of times the character is repeated. + This effect can be had by using parameter arithmetic with + `%'-sequences to compute the amount of padding, then generating + the result as a number at the front of the string so that `tputs' + will treat it as padding. + +`hz' + Flag whose presence means that the ASCII character `~' cannot be + output on this terminal because it is used for display commands. + + Programs handle this flag by checking all text to be output and + replacing each `~' with some other character(s). If this is not + done, the screen will be thoroughly garbled. + + The old Hazeltine terminals that required such treatment are + probably very rare today, so you might as well not bother to + support this flag. + +`CC' + String whose presence means the terminal has a settable command + character. The value of the string is the default command + character (which is usually ESC). + + All the strings of commands in the terminal description should be + written to use the default command character. If you are writing + an application program that changes the command character, use the + `CC' capability to figure out how to translate all the display + commands to work with the new command character. + + Most programs have no reason to look at the `CC' capability. + +`xb' + Flag whose presence identifies Superbee terminals which are unable + to transmit the characters ESC and `Control-C'. Programs which + support this flag are supposed to check the input for the code + sequences sent by the F1 and F2 keys, and pretend that ESC or + `Control-C' (respectively) had been read. But this flag is + obsolete, and not worth supporting. + + +File: termcap.info, Node: Screen Size, Next: Cursor Motion, Prev: Basic, Up: Capabilities + +Screen Size +=========== + + A terminal description has two capabilities, `co' and `li', that +describe the screen size in columns and lines. But there is more to +the question of screen size than this. + + On some operating systems the "screen" is really a window and the +effective width can vary. On some of these systems, `tgetnum' uses the +actual width of the window to decide what value to return for the `co' +capability, overriding what is actually written in the terminal +description. On other systems, it is up to the application program to +check the actual window width using a system call. For example, on BSD +4.3 systems, the system call `ioctl' with code `TIOCGWINSZ' will tell +you the current screen size. + + On all window systems, termcap is powerless to advise the application +program if the user resizes the window. Application programs must deal +with this possibility in a system-dependent fashion. On some systems +the C shell handles part of the problem by detecting changes in window +size and setting the `TERMCAP' environment variable appropriately. +This takes care of application programs that are started subsequently. +It does not help application programs already running. + + On some systems, including BSD 4.3, all programs using a terminal get +a signal named `SIGWINCH' whenever the screen size changes. Programs +that use termcap should handle this signal by using `ioctl TIOCGWINSZ' +to learn the new screen size. + +`co' + Numeric value, the width of the screen in character positions. + Even hardcopy terminals normally have a `co' capability. + +`li' + Numeric value, the height of the screen in lines. + + +File: termcap.info, Node: Cursor Motion, Next: Wrapping, Prev: Screen Size, Up: Capabilities + +Cursor Motion +============= + + Termcap assumes that the terminal has a "cursor", a spot on the +screen where a visible mark is displayed, and that most display +commands take effect at the position of the cursor. It follows that +moving the cursor to a specified location is very important. + + There are many terminal capabilities for different cursor motion +operations. A terminal description should define as many as possible, +but most programs do not need to use most of them. One capability, +`cm', moves the cursor to an arbitrary place on the screen; this by +itself is sufficient for any application as long as there is no need to +support hardcopy terminals or certain old, weak displays that have only +relative motion commands. Use of other cursor motion capabilities is an +optimization, enabling the program to output fewer characters in some +common cases. + + If you plan to use the relative cursor motion commands in an +application program, you must know what the starting cursor position +is. To do this, you must keep track of the cursor position and update +the records each time anything is output to the terminal, including +graphic characters. In addition, it is necessary to know whether the +terminal wraps after writing in the rightmost column. *Note Wrapping::. + + One other motion capability needs special mention: `nw' moves the +cursor to the beginning of the following line, perhaps clearing all the +starting line after the cursor, or perhaps not clearing at all. This +capability is a least common denominator that is probably supported +even by terminals that cannot do most other things such as `cm' or `do'. +Even hardcopy terminals can support `nw'. + +`cm' + String of commands to position the cursor at line L, column C. + Both parameters are origin-zero, and are defined relative to the + screen, not relative to display memory. + + All display terminals except a few very obsolete ones support `cm', + so it is acceptable for an application program to refuse to + operate on terminals lacking `cm'. + +`ho' + String of commands to move the cursor to the upper left corner of + the screen (this position is called the "home position"). In + terminals where the upper left corner of the screen is not the + same as the beginning of display memory, this command must go to + the upper left corner of the screen, not the beginning of display + memory. + + Every display terminal supports this capability, and many + application programs refuse to operate if the `ho' capability is + missing. + +`ll' + String of commands to move the cursor to the lower left corner of + the screen. On some terminals, moving up from home position does + this, but programs should never assume that will work. Just + output the `ll' string (if it is provided); if moving to home + position and then moving up is the best way to get there, the `ll' + command will do that. + +`cr' + String of commands to move the cursor to the beginning of the line + it is on. If this capability is not specified, many programs + assume they can use the ASCII carriage return character for this. + +`le' + String of commands to move the cursor left one column. Unless the + `bw' flag capability is specified, the effect is undefined if the + cursor is at the left margin; do not use this command there. If + `bw' is present, this command may be used at the left margin, and + it wraps the cursor to the last column of the preceding line. + +`nd' + String of commands to move the cursor right one column. The + effect is undefined if the cursor is at the right margin; do not + use this command there, not even if `am' is present. + +`up' + String of commands to move the cursor vertically up one line. The + effect of sending this string when on the top line is undefined; + programs should never use it that way. + +`do' + String of commands to move the cursor vertically down one line. + The effect of sending this string when on the bottom line is + undefined; programs should never use it that way. + + Some programs do use `do' to scroll up one line if used at the + bottom line, if `sf' is not defined but `sr' is. This is only to + compensate for certain old, incorrect terminal descriptions. (In + principle this might actually lead to incorrect behavior on other + terminals, but that seems to happen rarely if ever.) But the + proper solution is that the terminal description should define + `sf' as well as `do' if the command is suitable for scrolling. + + The original idea was that this string would not contain a newline + character and therefore could be used without disabling the + kernel's usual habit of converting of newline into a + carriage-return newline sequence. But many terminal descriptions + do use newline in the `do' string, so this is not possible; a + program which sends the `do' string must disable output conversion + in the kernel (*note Initialize::.). + +`bw' + Flag whose presence says that `le' may be used in column zero to + move to the last column of the preceding line. If this flag is + not present, `le' should not be used in column zero. + +`nw' + String of commands to move the cursor to start of next line, + possibly clearing rest of line (following the cursor) before + moving. + +`DO', `UP', `LE', `RI' + Strings of commands to move the cursor N lines down vertically, up + vertically, or N columns left or right. Do not attempt to move + past any edge of the screen with these commands; the effect of + trying that is undefined. Only a few terminal descriptions provide + these commands, and most programs do not use them. + +`CM' + String of commands to position the cursor at line L, column C, + relative to display memory. Both parameters are origin-zero. + This capability is present only in terminals where there is a + difference between screen-relative and memory-relative addressing, + and not even in all such terminals. + +`ch' + String of commands to position the cursor at column C in the same + line it is on. This is a special case of `cm' in which the + vertical position is not changed. The `ch' capability is provided + only when it is faster to output than `cm' would be in this + special case. Programs should not assume most display terminals + have `ch'. + +`cv' + String of commands to position the cursor at line L in the same + column. This is a special case of `cm' in which the horizontal + position is not changed. The `cv' capability is provided only + when it is faster to output than `cm' would be in this special + case. Programs should not assume most display terminals have `cv'. + +`sc' + String of commands to make the terminal save the current cursor + position. Only the last saved position can be used. If this + capability is present, `rc' should be provided also. Most + terminals have neither. + +`rc' + String of commands to make the terminal restore the last saved + cursor position. If this capability is present, `sc' should be + provided also. Most terminals have neither. + +`ff' + String of commands to advance to the next page, for a hardcopy + terminal. + +`ta' + String of commands to move the cursor right to the next hardware + tab stop column. Missing if the terminal does not have any kind of + hardware tabs. Do not send this command if the kernel's terminal + modes say that the kernel is expanding tabs into spaces. + +`bt' + String of commands to move the cursor left to the previous hardware + tab stop column. Missing if the terminal has no such ability; many + terminals do not. Do not send this command if the kernel's + terminal modes say that the kernel is expanding tabs into spaces. + + The following obsolete capabilities should be included in terminal +descriptions when appropriate, but should not be looked at by new +programs. + +`nc' + Flag whose presence means the terminal does not support the ASCII + carriage return character as `cr'. This flag is needed because + old programs assume, when the `cr' capability is missing, that + ASCII carriage return can be used for the purpose. We use `nc' to + tell the old programs that carriage return may not be used. + + New programs should not assume any default for `cr', so they need + not look at `nc'. However, descriptions should contain `nc' + whenever they do not contain `cr'. + +`xt' + Flag whose presence means that the ASCII tab character may not be + used for cursor motion. This flag exists because old programs + assume, when the `ta' capability is missing, that ASCII tab can be + used for the purpose. We use `xt' to tell the old programs not to + use tab. + + New programs should not assume any default for `ta', so they need + not look at `xt' in connection with cursor motion. Note that `xt' + also has implications for standout mode (*note Standout::.). It + is obsolete in regard to cursor motion but not in regard to + standout. + + In fact, `xt' means that the terminal is a Teleray 1061. + +`bc' + Very obsolete alternative name for the `le' capability. + +`bs' + Flag whose presence means that the ASCII character backspace may be + used to move the cursor left. Obsolete; look at `le' instead. + +`nl' + Obsolete capability which is a string that can either be used to + move the cursor down or to scroll. The same string must scroll + when used on the bottom line and move the cursor when used on any + other line. New programs should use `do' or `sf', and ignore `nl'. + + If there is no `nl' capability, some old programs assume they can + use the newline character for this purpose. These programs follow + a bad practice, but because they exist, it is still desirable to + define the `nl' capability in a terminal description if the best + way to move down is *not* a newline. + + +File: termcap.info, Node: Wrapping, Next: Scrolling, Prev: Cursor Motion, Up: Capabilities + +Wrapping +======== + + "Wrapping" means moving the cursor from the right margin to the left +margin of the following line. Some terminals wrap automatically when a +graphic character is output in the last column, while others do not. +Most application programs that use termcap need to know whether the +terminal wraps. There are two special flag capabilities to describe +what the terminal does when a graphic character is output in the last +column. + +`am' + Flag whose presence means that writing a character in the last + column causes the cursor to wrap to the beginning of the next line. + + If `am' is not present, writing in the last column leaves the + cursor at the place where the character was written. + + Writing in the last column of the last line should be avoided on + terminals with `am', as it may or may not cause scrolling to occur + (*note Scrolling::.). Scrolling is surely not what you would + intend. + + If your program needs to check the `am' flag, then it also needs + to check the `xn' flag which indicates that wrapping happens in a + strange way. Many common terminals have the `xn' flag. + +`xn' + Flag whose presence means that the cursor wraps in a strange way. + At least two distinct kinds of strange behavior are known; the + termcap data base does not contain anything to distinguish the two. + + On Concept-100 terminals, output in the last column wraps the + cursor almost like an ordinary `am' terminal. But if the next + thing output is a newline, it is ignored. + + DEC VT-100 terminals (when the wrap switch is on) do a different + strange thing: the cursor wraps only if the next thing output is + another graphic character. In fact, the wrap occurs when the + following graphic character is received by the terminal, before the + character is placed on the screen. + + On both of these terminals, after writing in the last column a + following graphic character will be displayed in the first column + of the following line. But the effect of relative cursor motion + characters such as newline or backspace at such a time depends on + the terminal. The effect of erase or scrolling commands also + depends on the terminal. You can't assume anything about what + they will do on a terminal that has `xn'. So, to be safe, you + should never do these things at such a time on such a terminal. + + To be sure of reliable results on a terminal which has the `xn' + flag, output a `cm' absolute positioning command after writing in + the last column. Another safe thing to do is to output + carriage-return newline, which will leave the cursor at the + beginning of the following line. + +`LP' + Flag whose presence means that it is safe to write in the last + column of the last line without worrying about undesired + scrolling. `LP' indicates the DEC flavor of `xn' strangeness. + + +File: termcap.info, Node: Scrolling, Next: Windows, Prev: Wrapping, Up: Capabilities + +Scrolling +========= + + "Scrolling" means moving the contents of the screen up or down one or +more lines. Moving the contents up is "forward scrolling"; moving them +down is "reverse scrolling". + + Scrolling happens after each line of output during ordinary output +on most display terminals. But in an application program that uses +termcap for random-access output, scrolling happens only when +explicitly requested with the commands in this section. + + Some terminals have a "scroll region" feature. This lets you limit +the effect of scrolling to a specified range of lines. Lines outside +the range are unaffected when scrolling happens. The scroll region +feature is available if either `cs' or `cS' is present. + +`sf' + String of commands to scroll the screen one line up, assuming it is + output with the cursor at the beginning of the bottom line. + +`sr' + String of commands to scroll the screen one line down, assuming it + is output with the cursor at the beginning of the top line. + +`do' + A few programs will try to use `do' to do the work of `sf'. This + is not really correct--it is an attempt to compensate for the + absence of a `sf' command in some old terminal descriptions. + + Since these terminal descriptions do define `sr', perhaps at one + time the definition of `do' was different and it could be used for + scrolling as well. But it isn't desirable to combine these two + functions in one capability, since scrolling often requires more + padding than simply moving the cursor down. Defining `sf' and + `do' separately allows you to specify the padding properly. Also, + all sources agree that `do' should not be relied on to do + scrolling. + + So the best approach is to add `sf' capabilities to the + descriptions of these terminals, copying the definition of `do' if + that does scroll. + +`SF' + String of commands to scroll the screen N lines up, assuming it is + output with the cursor at the beginning of the bottom line. + +`SR' + String of commands to scroll the screen N lines down, assuming it + is output with the cursor at the beginning of the top line. + +`cs' + String of commands to set the scroll region. This command takes + two parameters, START and END, which are the line numbers + (origin-zero) of the first line to include in the scroll region + and of the last line to include in it. When a scroll region is + set, scrolling is limited to the specified range of lines; lines + outside the range are not affected by scroll commands. + + Do not try to move the cursor outside the scroll region. The + region remains set until explicitly removed. To remove the scroll + region, use another `cs' command specifying the full height of the + screen. + + The cursor position is undefined after the `cs' command is set, so + position the cursor with `cm' immediately afterward. + +`cS' + String of commands to set the scroll region using parameters in + different form. The effect is the same as if `cs' were used. + Four parameters are required: + + 1. Total number of lines on the screen. + + 2. Number of lines above desired scroll region. + + 3. Number of lines below (outside of) desired scroll region. + + 4. Total number of lines on the screen, the same as the first + parameter. + + This capability is a GNU extension that was invented to allow the + Ann Arbor Ambassador's scroll-region command to be described; it + could also be done by putting non-Unix `%'-sequences into a `cs' + string, but that would have confused Unix programs that used the + `cs' capability with the Unix termcap. Currently only GNU Emacs + uses the `cS' capability. + +`ns' + Flag which means that the terminal does not normally scroll for + ordinary sequential output. For modern terminals, this means that + outputting a newline in ordinary sequential output with the cursor + on the bottom line wraps to the top line. For some obsolete + terminals, other things may happen. + + The terminal may be able to scroll even if it does not normally do + so. If the `sf' capability is provided, it can be used for + scrolling regardless of `ns'. + +`da' + Flag whose presence means that lines scrolled up off the top of the + screen may come back if scrolling down is done subsequently. + + The `da' and `db' flags do not, strictly speaking, affect how to + scroll. But programs that scroll usually need to clear the lines + scrolled onto the screen, if these flags are present. + +`db' + Flag whose presence means that lines scrolled down off the bottom + of the screen may come back if scrolling up is done subsequently. + +`lm' + Numeric value, the number of lines of display memory that the + terminal has. A value of zero means that the terminal has more + display memory than can fit on the screen, but no fixed number of + lines. (The number of lines may depend on the amount of text in + each line.) + + Any terminal description that defines `SF' should also define `sf'; +likewise for `SR' and `sr'. However, many terminals can only scroll by +one line at a time, so it is common to find `sf' and not `SF', or `sr' +without `SR'. + + Therefore, all programs that use the scrolling facilities should be +prepared to work with `sf' in the case that `SF' is absent, and +likewise with `sr'. On the other hand, an application program that +uses only `sf' and not `SF' is acceptable, though slow on some +terminals. + + When outputting a scroll command with `tputs', the NLINES argument +should be the total number of lines in the portion of the screen being +scrolled. Very often these commands require padding proportional to +this number of lines. *Note Padding::. + + +File: termcap.info, Node: Windows, Next: Clearing, Prev: Scrolling, Up: Capabilities + +Windows +======= + + A "window", in termcap, is a rectangular portion of the screen to +which all display operations are restricted. Wrapping, clearing, +scrolling, insertion and deletion all operate as if the specified +window were all the screen there was. + +`wi' + String of commands to set the terminal output screen window. This + string requires four parameters, all origin-zero: + 1. The first line to include in the window. + + 2. The last line to include in the window. + + 3. The first column to include in the window. + + 4. The last column to include in the window. + + Most terminals do not support windows. + + +File: termcap.info, Node: Clearing, Next: Insdel Line, Prev: Windows, Up: Capabilities + +Clearing Parts of the Screen +============================ + + There are several terminal capabilities for clearing parts of the +screen to blank. All display terminals support the `cl' string, and +most display terminals support all of these capabilities. + +`cl' + String of commands to clear the entire screen and position the + cursor at the upper left corner. + +`cd' + String of commands to clear the line the cursor is on, and all the + lines below it, down to the bottom of the screen. This command + string should be used only with the cursor in column zero; their + effect is undefined if the cursor is elsewhere. + +`ce' + String of commands to clear from the cursor to the end of the + current line. + +`ec' + String of commands to clear N characters, starting with the + character that the cursor is on. This command string is expected + to leave the cursor position unchanged. The parameter N should + never be large enough to reach past the right margin; the effect + of such a large parameter would be undefined. + + Clear to end of line (`ce') is extremely important in programs that +maintain an updating display. Nearly all display terminals support this +operation, so it is acceptable for a an application program to refuse to +work if `ce' is not present. However, if you do not want this +limitation, you can accomplish clearing to end of line by outputting +spaces until you reach the right margin. In order to do this, you must +know the current horizontal position. Also, this technique assumes +that writing a space will erase. But this happens to be true on all +the display terminals that fail to support `ce'. + + +File: termcap.info, Node: Insdel Line, Next: Insdel Char, Prev: Clearing, Up: Capabilities + +Insert/Delete Line +================== + + "Inserting a line" means creating a blank line in the middle of the +screen, and pushing the existing lines of text apart. In fact, the +lines above the insertion point do not change, while the lines below +move down, and one is normally lost at the bottom of the screen. + + "Deleting a line" means causing the line to disappear from the +screen, closing up the gap by moving the lines below it upward. A new +line appears at the bottom of the screen. Usually this line is blank, +but on terminals with the `db' flag it may be a line previously moved +off the screen bottom by scrolling or line insertion. + + Insertion and deletion of lines is useful in programs that maintain +an updating display some parts of which may get longer or shorter. +They are also useful in editors for scrolling parts of the screen, and +for redisplaying after lines of text are killed or inserted. + + Many terminals provide commands to insert or delete a single line at +the cursor position. Some provide the ability to insert or delete +several lines with one command, using the number of lines to insert or +delete as a parameter. Always move the cursor to column zero before +using any of these commands. + +`al' + String of commands to insert a blank line before the line the + cursor is on. The existing line, and all lines below it, are + moved down. The last line in the screen (or in the scroll region, + if one is set) disappears and in most circumstances is discarded. + It may not be discarded if the `db' is present (*note + Scrolling::.). + + The cursor must be at the left margin before this command is used. + This command does not move the cursor. + +`dl' + String of commands to delete the line the cursor is on. The + following lines move up, and a blank line appears at the bottom of + the screen (or bottom of the scroll region). If the terminal has + the `db' flag, a nonblank line previously pushed off the screen + bottom may reappear at the bottom. + + The cursor must be at the left margin before this command is used. + This command does not move the cursor. + +`AL' + String of commands to insert N blank lines before the line that + the cursor is on. It is like `al' repeated N times, except that + it is as fast as one `al'. + +`DL' + String of commands to delete N lines starting with the line that + the cursor is on. It is like `dl' repeated N times, except that + it is as fast as one `dl'. + + Any terminal description that defines `AL' should also define `al'; +likewise for `DL' and `dl'. However, many terminals can only insert or +delete one line at a time, so it is common to find `al' and not `AL', +or `dl' without `DL'. + + Therefore, all programs that use the insert and delete facilities +should be prepared to work with `al' in the case that `AL' is absent, +and likewise with `dl'. On the other hand, it is acceptable to write +an application that uses only `al' and `dl' and does not look for `AL' +or `DL' at all. + + If a terminal does not support line insertion and deletion directly, +but does support a scroll region, the effect of insertion and deletion +can be obtained with scrolling. However, it is up to the individual +user program to check for this possibility and use the scrolling +commands to get the desired result. It is fairly important to implement +this alternate strategy, since it is the only way to get the effect of +line insertion and deletion on the popular VT100 terminal. + + Insertion and deletion of lines is affected by the scroll region on +terminals that have a settable scroll region. This is useful when it is +desirable to move any few consecutive lines up or down by a few lines. +*Note Scrolling::. + + The line pushed off the bottom of the screen is not lost if the +terminal has the `db' flag capability; instead, it is pushed into +display memory that does not appear on the screen. This is the same +thing that happens when scrolling pushes a line off the bottom of the +screen. Either reverse scrolling or deletion of a line can bring the +apparently lost line back onto the bottom of the screen. If the +terminal has the scroll region feature as well as `db', the pushed-out +line really is lost if a scroll region is in effect. + + When outputting an insert or delete command with `tputs', the NLINES +argument should be the total number of lines from the cursor to the +bottom of the screen (or scroll region). Very often these commands +require padding proportional to this number of lines. *Note Padding::. + + For `AL' and `DL' the NLINES argument should *not* depend on the +number of lines inserted or deleted; only the total number of lines +affected. This is because it is just as fast to insert two or N lines +with `AL' as to insert one line with `al'. + |