This item text has been erased.

46 responses total.

Hmm, doesn't happen to me.  Do the folks who are complaining have
anything in common, such as using a particular terminal type, or
a particular communications program?

This response has been erased.

(I'm betting is has something to do with the number of rows on Grex vs.
the number of rows on home computer.)

Another question:  Does the problem occur only with the "less" pager
but not with the "more" pager.

(I'll vouch for the problem NOT occurring with the more pager, which is why
I prefer it.)

I've never seen it happen with more.

But you have with "less", I take it?

This response has been erased.

(I've had it with "less"...)

(maybe I should phrase that another way. nah.)

I have sometimes had a problem with more deciding to clear the bottom
line of the screen both before and after it prints the first line of
the next screen, leaving a blank line in the middle of the text i'm viewing.
This behaviour convinced me to change to less.

Weird.  I guess I'm the local termcap and terminal emulation guru
as much as anyone, so I'd be willing to try to trouble-shoot this.
But I haven't experienced the problem myself ("more" and "less" both
work correctly for me), so I need more data.  If anyone has problems
with either "more" or "less", please describe (1) the symptoms,
(2) your terminal type on Grex (vt100, vt220, ansi, or whatever),
(3) what communication program you use, (4) what terminal emulation
your comm. program is set to.  Thanks.

(my problem with "less" is a result of my rows on Grex being a different
number than my rows on my comm. program. I know what the problem is, but I
don't feel like fixing it. I'd rather use more than less.)

(this is starting to feel surreal, let me tell you...)

If your comm. program is set for a smaller number of rows than Grex
thinks you have, that would account for the top on or more lines 
scrolling off the top of the screen prematurely, but not for the
unwanted clearing of lines that other people seem to experience.
And it wouldn't account for a difference between "more" and "less"
either.  Anybody else with pager problems care to relate their
symptoms.?

(actually, my comm. program is set for a *larger* number of rows than Grex
thinks. This doesn't adversely affect the "more" pager for me, but it does
seem to throw off the "less" pager. If I set both equal, or at least within
2 of each other, I don't have any obvious problems.)

This is because less uses the entire screen to scroll, but then moves
the cursor to what *it* thinks should be the last line before it prints the
prompt.

(that makes sense.)

This response has been erased.

#15 makes sense.  Does Pattie's terminal screen have more than the
standard number of lines (24) for a VT100?

This response has been erased.

This response has been erased.

well, I had troubles with less, specifically with my last line being
erased.  I think I know what is wrong, I just never bothered to see
if I was correct.  I'm using TELIX/vt102, I have the screen in 25 line
mode, and stty reports 24 lines, so in most cases, like more, I just get
to keep an extra line at the top.  less, however, looks like it sends
the command to put the cursor at the 24th line from the top when getting
ready to continue, which of course is one too few lines for my screen.

Right, that's what happens, as mju pointed out earlier.  "Less" moves
the cursor to what it *thinks* is the last line on the screen, clears
the line, which unfortunately contains text.  The solution is to make
sure grex knows how many lines are on your display.  The command
"stty rows 25" will do it if you have 25 lines.

How would you configure things if you WANTED, say, a 2-3 line overlap 
from the last screen for continuity sake?
  
I have 35 rows, but configure for 32, vi doesn't mind either.

With "less", I think you'd use the -z option, which defines the
"window size".  e.g. "less -z 20" would cause the screen to scroll
forward 20 lines when you go to the next screen, giving you 4 lines
of overlap on a 24-line display.

I believe "less" give you 1 or 2 lines of overlap by default.

Don't know if this item's still alive, but on the offchange:  I'm having pre-
cisely the problem discussed herein with the "less" pager, which seems to
have been the default option I got when I first started using the system.  I'm
*real* new to this, so forgive me if I'm making egregious newbie mistakes!  
What happens is that the "Press spacebar for more, q to quit" prompt replaces
what I think must be the next line of text in whatever I'm reading; when I
press spacebar, the line that would have been "under" the prompt is erased,
and so effectively a line is skipped.  I'm still trying to figure out how
my comm. software, Versaterm, works (the manuals seem to have been written in
something that is almost but not entirely unlike English, so I'm exploring on
my own), so I'm not sure I've got it set right; if I do, both my terminal and
Grex for me are set to vt100.  ???

And, while I'm at it:  at *what* prompt is it that one can type handy things
like stty rows 25 in order to effect some kind of useful change?

Thanks...!

Partial answer: if you want stty rows 25 permanently, add it to your
.profile file. Otherwise, it'd be  !stty rows 25  at an Ok: prompt, but
it would be good for that session only. By the way, I use Versaterm, and
I agree that the manual is awful (the configuration structure is awful
too).

This response has been erased.

Old items never die; they just go to sleep.  Often a gentle nudge in
the form of a new response is sufficent to wake them up.

The solution is probably somewhere in the previous discussion.  (To
re-read an item from the beginning, type 0 at a "Respond or pass"
prompt -- this show you everything from the beginning, i.e. response
#0.)

I think you need to make sure that the actual number of lines on your
screen is the same as what Grex thinks it is, either by resizing your
terminal window (if you're using a windowing system) or by issuing an
"stty rows" command on Grex.  (You can issue a unix command from almost
any prompt by prefixing it with "!".  If you put the command in your
.profile or .login, though, you should *not* prefix it with a "!".)

Most terminal types on Grex default to 24 lines if you don't explicitly
set the number of rows via stty.  If you use the default but your
terminal actually has 25 lines, that would cause the problem you've
been having.

(Valerie slipped in...)

Just noticed an announcement on Usenet for a new verions of Less
(v 2.55, I think).  It has a few more options, but looked somewhat
esoteric to me (less already has a bazillion options).  I haven't
tried looking for the source yet.  Has anyone else?

Not me, but thanks for the pointer.  I'll try to grab it and have
a look when I get the chance.

(re 30: I meant the new options looked esoteric, not that all less
options are so.  Also s/versions/version/ in line 1.  I think I saw
the announcement in alt.sources.bugs, of all places.).

I've had a little problem with Less scrolling too far if people enter more
than 80 characters on a line, that seems to confuse it and it scrolls past
the top of the screen.  Is the only way to fix that to lower the number of
lines?  Just checking...

This response has been erased.

I believe "b" in less will back you up a page and "d" will advance you
by half a page.  If some of the page scrolled off the top of your screen,
"bd" should let you read it.  Also remember that a carriage-return will
advance by only one line, so you can step through the text very slowly
and carefully that way.

I think that might be "u".  If I recall correctly, "b" backscrolls by
a full page.

The behavior of scrolling too far when there is line wrap sounds like
a bug -- "less" should be able to tell when lines wrap and compensate
for it by not scrolling as far.

Ah.  I feel much enlightened - many thanks - I'll experiment and see if I 
can become scribble-free once more.  

Re #28:  in truth, John, I did read all the way through the responses to this
one before I made my own.  Of course, this was made somewhat more difficult
by the fact that key lines - usually containing vitally important commands -
were being erased by the less pager...!  Much of what was said prior to my
response was useful, but what was said *afterwards* was - in deference to 
my avowed ignorance, perhaps - phrased a little differently and so was clearer
to me.  I'm grateful for the advice on how to read an item again from the be-
ginning!

Re #26:  it's nice to know it's not just me, Rane.

Hmm.  I just had a thought.  For the long-line problems, you could always
define your filter to run Picospan text through   fmt -c  before it goes
into less.  That should wrap long lines about as gracefully as possible,
without confusing less.

Um, make that    fmt -s   .  I got my options mixed up.  I sure wish there
were a way to modify a response you've just made, if no one's responded to
it yet.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss