jeffb@grace.cs.washington.edu (Jeff Bowden) (04/19/89)
I often run emacs over a 1200 baud line to a 49x80 vt100 emulator using the TERMCAP at the end of this article. When a portion of the screen is drawn (e.g. when I switch buffers) emacs goes through a routine of erasing each line (with a vt100 escape sequence) and painting the characters onto the screen. The problem is that if there are leading or embedded spaces in a give line, they are _printed_ onto the screen. This is not fatal - it gives the correct result - but it is a waste of time since those positions are already blank (this is especially annoying when things are in columns such as RMAIL-summary). Can this be fixed by twiddling the TERMCAP or does it require a fix to emacs itself? Here is the TERMCAP we have for vt100 on our Ultrix 2.3 system: -- -- d1|vt100|vt-100|pt100|pt-100:co#80:li#49:pt:cl=50\E[;H\E[2J:bs:cm=\E[%i%d;%dH:nd=2\E[C:up=2\E[A:ce=4\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:is=\E>\E[?3l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:if=/usr/lib/tabset/vt100:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kh=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:sr=2\EM:sf=2\ED:cs=\E[%i%d;%dr: -- --
jr@bbn.com (John Robinson) (04/19/89)
In article <JEFFB.89Apr18132711@grace.cs.washington.edu>, jeffb@grace (Jeff Bowden) writes: >I often run emacs over a 1200 baud line to a 49x80 vt100 emulator using the >TERMCAP at the end of this article. > >When a portion of the screen is drawn (e.g. when I switch buffers) emacs goes >through a routine of erasing each line (with a vt100 escape sequence) and >painting the characters onto the screen. The problem is that if there are >leading or embedded spaces in a give line, they are _printed_ onto the screen. >This is not fatal - it gives the correct result - but it is a waste of time >since those positions are already blank (this is especially annoying when >things are in columns such as RMAIL-summary). > >Can this be fixed by twiddling the TERMCAP or does it require a fix to emacs >itself? You are suggesting that it send the cursor motion comand, right? Let's see, I need to go to column 5 on line 13. I'll just send this little ol' string: ESC [ 1 3 ; 5 H Those 7 characters sure beat the 4 spaces I would have sent the other way. Be glad emacs is taking the quicker route, especially at 1200 baud. Going to column 9 you say? Emacs should send tab characters,possibly in combination with backspaces... Eventually there will be a column position where the cursor motion is the best way to go, and emacs should send it. In other words, it looks at the lengths of the possible strings to position the cursor, and chooses the shortest string to send. I haven't the time to run the experiment to determine this, but if you are interested do an open-termscript and look at what comes out. Or maybe you meant it to send the non-destructive space (aka cursor-right) command "ESC [ C" 4 times? (Plus two miliseconds of padding each time, according to your termcap). -- /jr jr@bbn.com or bbn!jr C'mon big money!
jeffb@grace.cs.washington.edu (Jeff Bowden) (04/20/89)
In article <38851@bbn.COM> jr@bbn.com (John Robinson) writes: >You are suggesting that it send the cursor motion comand, right? >Let's see, I need to go to column 5 on line 13. I'll just send this >little ol' string: > > ESC [ 1 3 ; 5 H > >Those 7 characters sure beat the 4 spaces I would have sent the other >way. Be glad emacs is taking the quicker route, especially at 1200 >baud. Going to column 9 you say? Emacs should send tab >characters,possibly in combination with backspaces... > I know about this. It just seemed to me that it was overstriking overly large expanses of spaces. >Eventually there will be a column position where the cursor motion is >the best way to go, and emacs should send it. In other words, it >looks at the lengths of the possible strings to position the cursor, >and chooses the shortest string to send. I haven't the time to run >the experiment to determine this, but if you are interested do an >open-termscript and look at what comes out. OK, I did just that. Here is what I found. For one line of an RMAIL-summary emacs output the following -- -- ^[[45;1H 79 13-Apr to: jbk xothello -- -- to produce this line -- -- 79 13-Apr to: jbk xothello -- -- where it could have done -- -- ^[[45;4H79 13-Apr^I^I^I to: jbk xothello -- -- That's 16 extra characters for this line. The second version took 41 chars so an increase of about 40%. It could be improved even further if you consider that just before it output this line it was somewhere in the line preceding it. So instead of the escape sequence which takes 7 chars it could have done "^M^J " which takes only 5 bringing us to a savings of 18 chars over what emacs does.