mike@yetti.UUCP (Mike Clarkson ) (07/04/87)
I'm glad that someone pointed out that termcap entries are designed for
the problem of syncing terminals and hosts. If you have your termcap
entry set right, you can run without flow control quite happily.
Though I strongly agree that binding ^S and ^Q to commonly used
functions is a bad idea, and just asks for trouble.
Just as important, someone pointed out that correct termcap are essential
for the proper functionality of any emacs: the display updating
algorithms depend on knowing how long it is going to take to carry out
a certain action. Based on the termcap values, Emacs decides whether
to re-write the text, or to scroll, or choose from whatever other
possibilities the terminal has to offer. It is therefore with mild anxiety
that I note that:
1) Every termcap file I have ever seen is different.
and 2) The chances of agreement between, and in some cases
within, a termcap file for any given entry is vanishingly small.
Take for example the much maligned, and ever present vt100. In
the current Emacs distribution, the scroll region capabilities (sr: sf:)
are disabled. Does this mean that in all of these years someone hasn't
figured out a way of making vt100's use scroll regions?
You've got to admit that it *is* an important functional requirement
for an Emacs.
Which brings me to the question (a feeble attempt to add light rather than
heat to this discussion). Does anyone have a good termcap entry for a vt100
in Smooth Scroll mode? If anything needs padding, this sucker does!
I have appended the termcap entry that I am using. It was derived from
a posting by Jeff Siegal, and is appended below. The delays
were arrived at empirically, and may have no real validity. If
anyone would care to swap termcap recipes, I would be interested.
Mike Clarkson, allegra \ SYMALG@YUSOL.BITNET
C.R.E.S.S., decvax \
York University, ihnp4 > !utzoo!yetti!mike.UUCP
4700 Keele Street, linus /
North York, Ontario, watmath / +1 (416) 736-2100 x 7767
M3J 1P3 Canada.
-------------------------------------------------------------------------------
From: Jeff Siegal <JBS%DEEP-THOUGHT%EDDIE.MIT.EDU@harvunxt.BITNET>
Subject: Much-improved Termcap Entries
Optimized termcap entries for common DEC terminals follow.
# modified by mike@yetti.UUCP to do smooth scroll
d0|vt100-80ss|vt100ss|vt100 with 80 columns - smooth scroll:\
:co#80:li#24:cl=50\E[;H\E[J:\
:do=2\ED:le=^H:bs:am:cm=45\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\
:ce=45\E[K:cd=50\E[J:so=5\E[7m:se=5\E[m:us=5\E[4m:ue=5\E[m:\
:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:\
:ks=\E=:ke=\E>:\
:kl=2\E[D:kr=2\E[C:ku=2\E[A:kd=2\E[B:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
:ho=25\E[H:pt:sr=95\EM:sf=95\ED:vt#3:xn:\
:sc=\E7:rc=\E8:cs=55\E[%i%d;%dr:
#Note: this is not really a generic vt200 entry, since vt240's need lots
#of padding and vt220's don't (see below)
d0|vt200-80ss|vt220-80ss|VT200 series with 80 columns - smooth scroll:\
:im=\E[4h:ei=\E[4l:ip=3:mi:dc=\E[P:dm=:ed=:al=4\E[L:dl=4\E[M:\
:ce=\E[K:cl=\E[H\E[J:cd=\E[J:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\
:AL=1*\E[%dL:DL=1*\E[%dM:DC=\E[%dP:\
:tc=vt100-80ss:
# original entries from Jeff Siegal
#From: Jeff Siegal <JBS%DEEP-THOUGHT%EDDIE.MIT.EDU@harvunxt.BITNET>
#Subject: Much-improved Termcap Entries
#Optimized termcap entries for common DEC terminals follow. Replace
#the top of your EMACSVAR_TERMCAP file and watch your terminal do
#magic.
#For some reason, the entries for 132 column mode don't seem to work--I
#think it may be an Emacs bug, but I haven't tested with the termcap
#entries from Harvard.
## For VMS, make sure not to use \n or ^J for nl or anything else.
#
d0|vt100-80|vt100|vt100 with 80 columns:\
:co#80:li#24:cl=50\E[;H\E[J:\
:do=2\ED:le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\
:ce=3\E[K:cd=50\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\
:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:\
:ks=\E=:ke=\E>:\
:kl=\E[D:kr=\E[C:ku=\E[A:kd=\E[B:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
:ho=\E[H:pt:sr=5\EM:sf=\ED:vt#3:xn:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:
#Note: this is not really a generic vt200 entry, since vt240's need lots
#of padding and vt220's don't (see below)
d0|vt200-80|vt220-80|VT200 series with 80 columns:\
:im=\E[4h:ei=\E[4l:ip=3:mi:dc=\E[P:dm=:ed=:al=4\E[L:dl=4\E[M:\
:ce=\E[K:cl=\E[H\E[J:cd=\E[J:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\
:AL=1*\E[%dL:DL=1*\E[%dM:DC=\E[%dP:\
:tc=vt100-80:
d0|vt200-132|vt220-132|vt200 with 132 columns:\
:co#132:tc=vt200-80:
d3|vt132-80|vt102-80|vt240-80|vt100avo-80|vt series plus avo 80col:\
:al=99\E[L:dl=99\E[M:\
:ei=\E[4l:im=\E[4h:ip=7:dc=7\E[P:tc=vt100-80:
d3|vt132-132|vt102-132|vt240-132|vt100avo-132|vt series plus avo, 132col:\
:co#132:tc=vt132-80:
## For VMS, make sure not to use \n for nl or anything else.
## The entry for vt200-80 disables sr and sf, they don't
## seem for work right.l
d0|vt200-80|vt100-80|vt125-80|VT 200/100/125 with 80 columns:\
:co#80:li#24:am:bs:pt:xn:cl=45\E[H\E[2J:\
:cm=%i\E[%d;%dH:nd=\E[C:up=\EM:ho=\E[H:ce=2\E[K:cd=2*\E[J:\
:nl=\E[B:cr=\r:s-r=10\EM:s-f=10\ED:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:LC:\
:kl=\E[D:kr=\E[C:ku=\E[A:kd=\E[B:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
:ks=\E=:ke=\E>:
d0|vt200-132|vt100-132|vt125-132|VT 200/100/125 with 132 columns:\
:co#132:li#24:am:bs:pt:xn:cl=45\E[H\E[2J:\
:cm=%i\E[%d;%dH:nd=\E[C:up=\EM:ho=\E[H:ce=2\E[K:cd=2*\E[J:\
:nl=\E[B:cr=\r:sr=5\EM:sf=30\E7\E[200H\ED\E8:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:LC:\
:kl=\E[D:kr=\E[C:ku=\E[A:kd=\E[B:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:
--
Mike Clarkson, ...!allegra \ BITNET: mike@YUYETTI or
CRESS, York University, ...!decvax \ SYMALG@YUSOL
4700 Keele Street, ...!ihnp4 > !utzoo!yetti!mike
North York, Ontario, ...!linus /
CANADA M3J 1P3. ...!watmath / Phone: +1 (416) 736-2100 x 7767
"...the most inevitable business communications system on the planet."
- ROLM magazine advertisement
which planet?oz@yetti.UUCP (Ozan Yigit) (07/06/87)
In article <491@yetti.UUCP> mike@yetti.UUCP (Mike Clarkson ) writes: > >Take for example the much maligned, and ever present vt100. In >the current Emacs distribution, the scroll region capabilities (sr: sf:) >are disabled. Does this mean that in all of these years someone hasn't >figured out a way of making vt100's use scroll regions? >You've got to admit that it *is* an important functional requirement >for an Emacs. > For a *proper* implementation of Scroll regions along with the true Goslings Dynamic Programming Algorithm for optimal screen updates, see MicroEmacs (V30 / vt100) or MicroGnuEmacs (Termcap). It works very well indeed. -- You see things, and you say "WHY?" Usenet: [decvax|ihnp4]!utzoo!yetti!oz But I dream things that never were; ......!seismo!mnetor!yetti!oz and say "WHY NOT?" Bitnet: oz@[yusol|yulibra|yuyetti] G. Bernard Shaw Phonet: [416] 736-5053 x 3976 Back To Methuselah
jr@LF-SERVER-2.BBN.COM (John Robinson) (07/06/87)
>> Does anyone have a good termcap entry for a vt100 >> in Smooth Scroll mode? You have to be kidding. If it could, emacs should take the vt100 out of smooth-scroll. Certianly the fastest update will generally be to repaint the entire screen than to wait for the scroll to happen. Since emacs finds the fastest update, an accurate termcap would appear to be broken because you would never see the scroll happen. So you would have to remove all forms of screen update, including clear-screen, and force it to use scrolling regions. But then it will doubtless decide your terminal is too dumb to run emacs. It would probably be right. Apologies in arrears for the nasty tone, if you have even gotten this far. /jr
mike@yetti.UUCP (Mike Clarkson ) (07/07/87)
In article <492@yetti.UUCP> oz@yetti.UUCP (Ozan Yigit) writes: In article <491@yetti.UUCP> mike@yetti.UUCP (Mike Clarkson ) writes: > >Take for example the much maligned, and ever present vt100. In >the current Emacs distribution, the scroll region capabilities (sr: sf:) >are disabled. Does this mean that in all of these years someone hasn't >figured out a way of making vt100's use scroll regions? >You've got to admit that it *is* an important functional requirement >for an Emacs. > For a *proper* implementation of Scroll regions along with the true Goslings Dynamic Programming Algorithm for optimal screen updates, see MicroEmacs (V30 / vt100) or MicroGnuEmacs (Termcap). It works very well indeed. You missed the point entirely. It's not the GNU Emacs algorithm that's faulty, it's the termcap distributed with GNU Emacs that has the scroll regions disabled. I'm quite confident in RMS' ability to implement a *proper* algorithm for screen updates. In article <8707061437.AA06719@ucbvax.Berkeley.EDU> John Robinson writes: >> Does anyone have a good termcap entry for a vt100 >> in Smooth Scroll mode? You have to be kidding. If it could, emacs should take the vt100 out of smooth-scroll. Certianly the fastest update will generally be to repaint the entire screen than to wait for the scroll to happen. Since emacs finds the fastest update, an accurate termcap would appear to be broken because you would never see the scroll happen. So you would have to remove all forms of screen update, including clear-screen, and force it to use scrolling regions. But then it will doubtless decide your terminal is too dumb to run emacs. It would probably be right. Maybe at 9600 baud, but it's not true at slow speeds. If you are yanking 3 or 4 lines at 1200 baud, scroll regions are indeed much faster. Moreover, the main reason for having a smooth scroll at low speeds is that it is much easier on the eyes than jump scroll. I work a lot with Gnu on a vt100 at 1200/2400 baud, and jump-mode plus no-scroll-region is horrible. Emacs will find the fastest way to update the screen *only* if it has an accurate termcap, and I would rather have Emacs figure it out than accept your certainty that the fastest way to update will be to repaint the entire screen. So my question remains - does anyone have a good vt100 entry for smooth scroll mode? -- Mike Clarkson, ...!allegra \ BITNET: mike@YUYETTI or CRESS, York University, ...!decvax \ SYMALG@YUSOL 4700 Keele Street, ...!ihnp4 > !utzoo!yetti!mike North York, Ontario, ...!linus / CANADA M3J 1P3. ...!watmath / Phone: +1 (416) 736-2100 x 7767 "...the most inevitable business communications system on the planet." - ROLM magazine advertisement which planet?
oz@yetti.UUCP (Ozan Yigit) (07/07/87)
In article <493@yetti.UUCP> mike@yetti.UUCP (Mike Clarkson ) writes: > >You missed the point entirely. It's not the GNU Emacs algorithm that's >faulty, it's the termcap distributed with GNU Emacs that has the scroll >regions disabled. I'm quite confident in RMS' ability to implement a >*proper* algorithm for screen updates. > Well.. somebody missed a point. If you consider that just about everything in GNU is done for a reason, it is quite possible that the termcap change also have a reason. What I tried to point out to you is that Gosling's algorithm, although computationally intensive, if implemented correctly, works beautifully with scroll-regions. I *know* RMS is capable of implementing a proper algorithm, but since his code has no references whatsoever (literature refs that is), I do not know *what* his algorithm is, and whether it is optimal, both computationally or reactionally. (read: minimum number of chars and esc sequences to update the screen.) oz -- You see things, and you say "WHY?" Usenet: [decvax|ihnp4]!utzoo!yetti!oz But I dream things that never were; ......!seismo!mnetor!yetti!oz and say "WHY NOT?" Bitnet: oz@[yusol|yulibra|yuyetti] G. Bernard Shaw Phonet: [416] 736-5257 x 3976 Back To Methuselah
jr@LF-SERVER-2.BBN.COM.UUCP (07/09/87)
>> In article <493@yetti.UUCP> mike@yetti.UUCP (Mike Clarkson ) writes: >> > >> >You missed the point entirely. It's not the GNU Emacs algorithm that's >> >faulty, it's the termcap distributed with GNU Emacs that has the scroll >> >regions disabled. From termcap.ucb in the 18.47: d0|vt100|vt100-am|vt100am|dec vt100:\ :do=^J:co#80:li#24:cl=50\E[;H\E[2J:sf=5\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ :rf=/usr/lib/tabset/vt100:\ :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=5\EM:vt#3:xn:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: And indeed emacs is using the scrolling region as I type on my vt100 (emulator) right now. Now Mike, as I recall, is a VMS user, and the termcap for VMS, termcap.dat, does not have the scrolling regions enabled. Try adding the cs= capability above if you wish to experiment. (or substitute termcap.ucb for termcap.dat if you dare). It could be a VMS dependency. Perhaps the vt100 driver in VMS thinks it knows where the scrolling region is, and messing with it in a user program is dangerous. /jr
ron@topaz.rutgers.edu (Ron Natalie) (07/10/87)
It would seem to me that the first thing EMACS wants to do is turn off smooth scrolling. EMACS has no "scroll" operation. Changes EMACS makes to the screen are supposed to appear instantaneous. You are not expected to try to read the screen during updates, so slowing the scroll down or making it smooth so you can see is not applicable. Scroll is only done because it is a cheap block move on most terminals. -Ron
gaynor@topaz.rutgers.edu (Silver) (07/11/87)
ron@topaz writes: > Changes EMACS makes to the screen are supposed to appear > instantaneous. This depends upon your environment. It is impossible to perform instantaneous screen updates in a "slow" atmosphere, ... > You are not expected to try to read the screen > during updates, so slowing the scroll down or making it smooth so > you can see is not applicable. ... where the user *will* notice updates. These may occur slowly enough that the user may be able to still read the screen, and even detect what updates are being made. To keep from distracting the user, these changes should be as innocuous as possible. For an example, a redraw is disconcerting in a slow environment. The eyes follow the line insertions (just after registering a gap in the material), and the thought "C'mon, c'mon..." registers unbidden in the mind. Almost without fail. With a (relatively) smooth scroll, though, the eyes and grey matter tend to stay focused on the attended material. It is more appropriate to say "The user will hopefully disregard the screen updates, so do them incognito.". > Scroll is only done because it is a > cheap block move on most terminals. Smooth-scroll is only done to maintain continuity in the display during updates for the benefit of the user. Normal scrolls and redraws might be a little faster. And a little uglier. Don't get me wrong, though. I'm NOT saying that everything should be smooth-scrolled, because it can also be distracting - it's almost as if material being smooth-scrolled has attention-glue on it if it's overused and performed *too* slowly. What I AM saying is that there are other considerations to be taken into account besides display- efficiency. What is efficient for the display is not always efficient for the user (although it seems that this is usually the case). Silver. name: Andy Gaynor (Silver) uucp: ...!rutgers!topaz.rutgers.edu!gaynor arpa: gaynor@topaz.rutgers.edu icbm: 40 34 N / 74 45 W
karl@haddock.UUCP (07/13/87)
In article <13269@topaz.rutgers.edu> gaynor@topaz.rutgers.edu (Silver) writes: >ron@topaz writes: >> Changes EMACS makes to the screen are supposed to appear instantaneous. > >This depends upon your environment. It is impossible to perform >instantaneous screen updates in a "slow" atmosphere, ... Well, it doesn't *have* to be impossible -- when I wrote my own terminal emulator a couple of years ago, one of the features I wanted was to have screen updates *appear* instantaneous even at low speed. The idea would be that modifications to the screen would take place in an invisible buffer; the emulator would then make them all at once. Unfortunately, this particular feature was never implemented; for one thing, there was no general way to tell when the "last" update was done. (Some features I did put in: 3-byte DCA; 1-byte arrows; ^J as a real newline; and (experimentally) keyboard ^S (when flow control was enabled at the emulator level) put the emulator into local mode until a keyboard ^Q was received. I really grew to like that last one!) (Now, let's justify posting this to comp.emacs.) There's one feature I didn't think of at the time, but would have been quite useful. Somewhere, in the chain of devices, switches, programs, and protocols that eventually led to an emacs, there was at least one gnome that insisted on processing ^S/^Q. I could have made an emacs-mode in which keyboard ^S, ^Q, and (say) ^R would map to ^RS, ^RQ, and ^RR, respectively; then had emacs* perform the reverse translation at the lowest possible level. This would've made the flow-control braindamage completely transparent. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint *It would be better to put this in the kernel, but I didn't have that option.
mike@yetti.UUCP (Mike Clarkson ) (07/16/87)
In article <8707091316.AA20406@ucbvax.Berkeley.EDU> jr@LF-SERVER-2.BBN.COM (John Robinson) writes: >From termcap.ucb in the 18.47: > ... >And indeed emacs is using the scrolling region as I type on my vt100 >(emulator) right now. > >Now Mike, as I recall, is a VMS user, and the termcap for VMS, >termcap.dat, does not have the scrolling regions enabled. Try adding >the cs= capability above if you wish to experiment. (or substitute >termcap.ucb for termcap.dat if you dare). > >It could be a VMS dependency. Perhaps the vt100 driver in VMS thinks >it knows where the scrolling region is, and messing with it in a user >program is dangerous. No, it has nothing to do with VMS. It's a termcap padding problem. The cs= capability is already defined in termcap.dat: it's the :sr and :sf capabilities that have been removed by calling them :s-r and :s-f respectively. With the right padding, the sr and sf features work fine under both Unix and VMS; there is no need to comment them out. And yes, I have used termcap.ucb for VMS and Unix and it makes no difference - neither work without changing the padding for *smooth scroll* vt100 terminals. You bring up an interesting point though, but it only makes matters worse. Hardly anyone uses Dec vt100's any more - everyone uses look-alikes, or these days, micros running some emulator. *Each of these may have a different rate at which they carry out a particular operation*, though in theory they are all "vt100's". (Try running under some MacIntosh emulators...) So it is possible that many vt100 entries would be required, depending on the particular emulator and mode. I agree with gaynor@topaz: in some cases, most importantly at slow speeds, smooth scroll can be a lot easier on your eyes. Almost none of these problems will show up at fast speeds, or if your emulator is running on a faster machine that a vt100 (remember it's a Z-80 in there). All I really wanted was a smooth scroll termcap entry that works... Mike. -- Mike Clarkson, ...!allegra \ BITNET: mike@YUYETTI or CRESS, York University, ...!decvax \ SYMALG@YUSOL 4700 Keele Street, ...!ihnp4 > !utzoo!yetti!mike North York, Ontario, ...!linus / CANADA M3J 1P3. ...!watmath / Phone: +1 (416) 736-2100 x 7767 "...the most inevitable business communications system on the planet." - ROLM magazine advertisement which planet?