SUMMARY: Overshooting on scrolling in cmdtool

From: Bob Rahe (
Date: Mon Feb 12 1996 - 10:23:30 CST

  Well, I've been waiting and hoping but... Only two people replied, thanks
to: (Kevin Sheehan {Consulting Poster Child})
      Peter Hesse <>

  Kevin suggested using xterm and altho that WOULD work, I've kind of grown
fond of the command tool and it's version of scrool bars.

  Peter and I exchanged a number of messages with various and sundry ideas
to try, unfortunately none seemed to work. They were:

>> Check out text.margin.bottom in the xview(3) manual.

  Which I tried with no success, then:

>>I got caught with the -default and -xrm options. I tried your commands and
>>they worked fine. I used the -xrm option which requires different syntax:
>>cmdtool -xrm text.margin.bottom:0
>>cmdtool -xrm text.margin.bottom:10
>>cmdtool -xrm text.margin.bottom:-1
>>These all seemed fine.
>>I'm running SunOS 4.1.3_U1; what are you using?

  Well, I'm running 4.1.3b and the commands SEEM to have an effect but not
exactly as expected. -1 was a disaster, wound up near the top of the screen,
0 seems to be what I'm seeing, which is to be expected since that is what
the man claims is the default, and 10 seemd to be the same problem as 0
but offset by 10. That is, it would be between 10 and 13 where 0 produced
between 0 and 3.

>>Wierd. Does a similar problem occur if you just cat a file?

  Hmmm, interestingly, not that I can force to happen. The only thing I
would notice that is different tho is that a 'h' command to mush (show the
headers) there are (very short) delays as he puts them out. Almost like
he puts it out in chunks - there is some processing going on as he outputs
the lines. I can't think of a way to simulate that with cat or ls or

  Maybe I'll try a trace on mush to see if it is outputting anything
strange and/or control sequences to the window.....

>>And just as I read the second line I thought 'control sequences'! It sounds
>>like it is mush-specific so a trace sounds like a good start. You might also
>>see if you can get the output in a file (cmdtool log? or trace -o perhaps) to
>>look for control sequences as trace shows only the first 32 (?) characters of
>>each write.

  I did, no control chars can be seen.....

>>Running out of ideas.

>>Try renaming ~/.Xdefaults and then starting cmdtool so you get the system

>>Also, check you are running the right cmdtool; there just might be another
>>one in your path. (I have to contend with systems containing 3 subtly
>>different xterms.)

Done and done. No change.

  So..... What I've done is just set up my reader to use 3 lines less than
the screen - it doesn't usually overshoot that.....

Original message:


Subject: Overshooting on scrolling in cmdtool

  I've looked thru the summaries and the answerbooks and I thought I had seen
this mentioned here before but I can't find anything now so...

  I'm using a command tool window to read my mail with mush (for example, the
problem occurs with other progs also) and depending on the timing of the
writes of lines to the window, the window seems to overshoot when scrolling.
That is, if I write out, say, 33 lines, and that is the window size, I may
wind up with the top two lines scrolled above the top and two blank lines
at the bottom with the prompt on the 3rd line from the bottom.

  This seems to be timing dependent since a program that outputs lines
relatively slowly doesn't seem to trigger this behavior. So it seems there
is probably a cmdtool setting (or textedit or???) I could use to keep that
from happening. A scrollahead setting? I've looked thru the cmdtool man
page and the xview page for the generic tool settings and came up empty.

  Thanks and I'll summarize.


|Bob Rahe, Delaware Tech&Comm Coll.| The American Bald Eagle is protected  |
|Computer Center, Dover, Delaware| by law, the unborn American baby isn't. |
|Internet: | Some of our laws are really for the birds.|

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:53 CDT