Less not scrolling immediately on long lines (xterm-256color vs vt100)

Question

When I press 'j' in a text file with long lines, it won't proceed to the next line until I've pressed j 'n' times.

So if I have a file:

a
b
c
d
e (long line that displays as 5 lines on screen)

And I only see a-d, when I press j, I have to press j five times for line e to appear.

I generally do clean installs when upgrading my laptop; I've just got a new MBP with Lion, so it's possible I've left something out of my previous settings, although this isn't a behaviour I've observed from less before. I can't see anything in .lessrc or LESS-style environmental variables. A quick Google didn't show anything either.

Ok - this is a terminal issue - my old config must've set my terminals to vt100, my new one leaves Lion's default of xterm-256color alone. If I "export TERM=vt100" everything works as it should - so what is broken in xterm-256color's terminfo? (/usr/share/terminfo/78/xterm-256color)

Thanks!

Answer 1

There doesn't seem to be a 'built-in' way to get less to follow physical lines instead of screen lines, although have you tried the '-S' (dash,capital-ess) option? It chops the lines instead of folding them. You can type -S to toggle the folding on/off while in less, and I have it set in my LESS environment variable to always chop, so physical lines == screen lines, and I can tap -S to fold them in if I need to for some reason. I usually just press 'l' or right arrow to scroll that way.

in your .bashrc, or .profile, or whatever:

EXPORT LESS=-S

will cause less to 'chop' versus fold as a default action. It would allow you to scroll as you desire, again.. entering -S (dash, capital-ess) will toggle fold/chop as you want.

There are a plethora of other useful options to place in $LESS, try it!

The $LESS env variable is the most convenient way to specify default options, although you could also use an alias:

alias less='less -S'

But that starts getting unwieldy.