rms@prep (10/26/85)
From: Richard M. Stallman <rms@prep> The termcap documentation does not define the meaning of the cs string well enough to avoid off-by-one errors. So I designed Emacs's conventions for use of the cs string to work with the cs string for the VT100 in the termcap file here. I don't know of any reason to think that this convention is less correct than any alternative. The file etc/TERMS that comes with Emacs defines precise calling conventions for the cs string. If you are having trouble, discard your preconceived notions and compare that file with the terminal documentation. Does anything besides GNU Emacs use the cs string?
joe@emacs.UUCP (Joe Chapman) (10/28/85)
<>
> Does anything besides GNU Emacs use the cs string?
Both CCA EMACS and vi use the cs string; I'd assume that most
terminfo/termcap screen editors use it. The alternative is pretty
awful, as anyone who scrolls backwards on a non-cs terminal can testify.
It seems to me that defining the behavior of cs to be that exhibited by
a vt100 is a reasonable thing to do. According to my reading, supported
by principles of textual criticism, this is what is implied by the 4.2
termcap(5) manual page.
We've had a related problem with vt100 look-alikes: on the vt100, cs
also homes the cursor; on some look-alikes it doesn't. If you try to be
clever about optimizing cursor motion you can end up in dimension Q.
--
Joe Chapman joe@cca-unix decvax!cca!emacs!joepeter@graffiti.UUCP (Peter da Silva) (10/30/85)
> Does anything besides GNU Emacs use the cs string?
Yes, my UNIX file system browser program uses it. I have had no problem with
standard :cs=...: entries, but have only tried two terminals that have this
feature... vt-100 and a weird one we call "shadow" because we don't know who
made it. Had to figure out the termcap for it by trial and error.
--
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!petergnu@l5.uucp (John Gilmore) (10/31/85)
(Or whatever the Arpanet equivalent -- INFO-TERMS@somwehere -- is.) There are probably people on that list who can actually answer these questions... Info-terms people: see net.emacs, where people have been trying to figure out what "sg#0" means (something special and undocumented?) and what the arguments to the "cs" string are...
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/01/85)
> Info-terms people: see net.emacs, where people have been trying to figure > out what "sg#0" means (something special and undocumented?) ... The meaning of "sg#0" is that it is unsafe to do cursor motions while in standout mode. This was supposed to be the rule anyway unless "ms" is specified, but the manual entries were confusing. The result of this confusion is that a termcap entry should use one of the following: { "sg" and no "ms"} => unsafe to move in standout mode { "sg" and "ms"} => safe to move in standout mode {no "sg" and "ms"} => safe to move in standout mode {no "sg" and no "ms"} is interpretation-dependent; don't use this combination (unless there is also no stand-out capability). > ... and what the arguments to the "cs" string are... The top and bottom line numbers of the scrolling region (inclusive, 0 origin). I wish the EMACS implementors would pay attention to "xo" and the initial terminal modes, also. There are a lot of terminals that require DC3/DC1 flow control, and trying to cheat by supplying generous NUL padding is NOT the right solution.
aks@umcp-cs.UUCP (Alan K. Stebbens) (11/03/85)
In article <2687@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >I wish the EMACS implementors would pay attention to "xo" and >the initial terminal modes, also. There are a lot of terminals >that require DC3/DC1 flow control, and trying to cheat by >supplying generous NUL padding is NOT the right solution. I agree. I have just recently ported GNU EMacs to our UNIX 4.2BSD, where we have H/Z-29's at our desks for software development terminals. The H/Z-29's cannot have their flow control disabled, except for whether or not to use hardware or software handshaking. Since our office's terminals are wired with four-wire connections, we can't use hardware handshaking (at least, not without rewiring each terminals' connector to use CTS or whatever). Thus, software handshaking (using XON/XOFF), are always enabled. UNIX handles the terminals just fine. GNU Emacs, however, likes to use the ^S's as the "i-search" command. I have, however, hacked in a fix to "keyboard.c" which seems to work (mostly, it does work for the screen updates, but, currently, still represses the ^S usage until the ^Q is also sent). Actually, the fix also included some changes to "TrmTERM.c". The net effect was to define "UpdateBegin" and redefine "UpdateEnd" so that they temporarily reset the "t_stop" and "t_start" characters to the appropriate values. This was for "CBREAK_INPUT" mode. For "INTERRUPT_INPUT" mode, a different approach was taken, I changed the input available interrupt routine (the SIGIO receiver), to catch the ^S and ^Q, but only during screen updates (posted by a global variable set/cleared by "UpdateBegin" and "UpdateEnd"). In summary, some kind of allowance for control flow should be made to GNU Emacs (even if it means changing the action of certain characters during, or not during, screen updates). Also, Zenith has a newer terminal, the H/Z-49, which allows flow control to be completely disabled; however, this will require padding at appropriate points, but also a proportional amount to the number of normal chars output, effectively reducing the baud rate (we use 9600 baud). I was hoping to see the latest version of GNU Emacs to see if someone had already fixed this problem. -- Alan Stebbens UUCP: ..seismo!umcp-cs!aks ARPA: aks@maryland
smith@ncoast.UUCP (Phil Smith) (11/03/85)
> Article <241@l5.uucp> > From: gnu@l5.uucp (John Gilmore) > Info-terms people: see net.emacs, where people have been trying to figure > out what "sg#0" means (something special and undocumented?) and what > the arguments to the "cs" string are... According to my manual "sg#0" means > Number of blank chars left by so or se. so&se being start and end of standout mode.
pajb@ulysses.UUCP (Paul Bennett) (11/04/85)
In article aks@umcp-cd.UUCP writes ........... >Also, Zenith has a newer terminal, the H/Z-49, which allows flow control to >be completely disabled; however, this will require padding at appropriate >points, but also a proportional amount to the number of normal chars output, >effectively reducing the baud rate (we use 9600 baud). Doesn't flow control cause the same thing ? I mean that's how it works, by temporariliy reducing the data rate, so the terminal can catch up. I've run GNUemacs on hp's and a Teletype 5620 running layers and standalone. By experimenting for about 10 minutes, I got the padding for the hp's just right - it now doesn't send a XOFF at all while running GNU emacs. I don't want to turn it off, because then it doesn't work with the rest of Unix properly. I can see NO difference in the effective baud/display rate, I have a VERY useful incremental search on the keys where it has always been (and which is mnemonic, too), and I have no problem with screen updates. I run at 9600 baud. Nowhere in the ASCII standard, or RS-232 for that matter, are DC1/DC3 defined as flow control characters. To use them for such is to implement a flow control scheme that is NOT transparent to the domain of possible transmission values. This is bad design. A flow control scheme which allows all possible values to pass unheeded is to be preferred. One such a scheme can be implemented by judicious use of padding - another is to make use of hardware flow control. This is of course the ideal, and is in line with RS-232. -- Paul. UUCP: {decvax,allegra,vax135,ucbvax}!ulysses!circe!pajb DDD: (201) 582 7346 USPS: AT&T Bell Labs, Room 5E-103, Murray Hill, NJ 07974 .. I don't care WHO you are, you're not walking on the water while I'M fishing.