If I invoke less in my xterm window which has the parameters: $ echo echo $TERM $LINES $COLUMNS xterm 24 80 I get a display of a file with some top lines skipped. It appears that the flag -S (chop long lines) is partially ignored or line length is not properly calculated. In this case, manually counted, dimensions 80x24 is correct. Same behaviour on other dimensions, same behaviour with Eterm.
can you paste an example of a file that doesn't display properly onto the bug report so we have a common test case?
Created attachment 7286 [details] Test case file This was one of the files with which the problem occured. The only thing that seems to be necessary for this qualification is ...long lines... At least I think so...
i think the problem is the -r option of less (since version 378-r1, the less ebuild writes 'LESS="-r"' to /etc/env.d/70less). try this: download the file i'll attach after this report (it contains the output of 'dmesg | head -24' on my box). using an xterm / rxvt with 24 lines and 80 columns, open the file with less (make sure $LESS is set to '-r'). scroll a single line down, a single line up again, one down, etc. ('j', 'k', 'j', 'k', ...). watch the last line (starting with 'Memory: xk/yk available ...'). it should double each time you scroll up again. setting $LESS to '-R' or unsetting it seems to solve the problem. however, it's definitely not a gentoo bug. i tested less versions 358, 374, 378 and 380beta with the same results. the only gentoo specific thing is the default -r option.
Created attachment 7304 [details] test file described in report above
Indeed. Without -r it appears to work perfectly.
so my question is, what is the reason that we would be setting -r by default?
from the less changelog: ----- *less-378-r1 (26 Dec 2002) 26 Dec 2002; Martin Schlemmer <azarah@gentoo.org> less-378-r1.ebuild : Add /etc/env.d/70less containing 'LESS="-r"' for groff-1.18 and later support. ----- i'm not a groff expert, so i can't judge this.
I've been having weird less problems for a while now. Specifically, when I search in some files, several lines around and including the one containing the found string disappear. When I scroll up, then down again, the missing lines reappear. I came to exactly the same conclusion as Jukka and Klaus: it is the "-r" option that is screwing things up. The manpage for less says about "-r" : "Thus, various display problems may result, such as long lines being split in the wrong place." So, I am sure that "-r" should not be a default option for less. Either nothing or perhaps -R should be the default. Less doesn't have anything to do with groff, AFAIK, except that output from groff is often piped into it, such as when running man. So, I am guessing that the "-r" option may have been added in relation to man, but making it default for less is not the right way to do it. I remember that some ebuild was updated recently which caused man output to be screwed up until I ran etc-update and used some changed configuration file, but I can't remember which one it was; I suspect there is a connection.
Sorry for the long lines; this is what I should have posted: I've been having weird less problems for a while now. Specifically, when I search in some files, several lines around and including the one containing the found string disappear. When I scroll up, then down again, the missing lines reappear. I came to exactly the same conclusion as Jukka and Klaus: it is the "-r" option that is screwing things up. The manpage for less says about "-r": "Thus, various display problems may result, such as long lines being split in the wrong place." So, I am sure that "-r" should not be a default option for less. Either nothing or perhaps "-R" should be the default. Less doesn't have anything to do with groff, AFAIK, except that output from groff is often piped into it, such as when running man. So, I am guessing that the "-r" option may have been added in relation to man, but making it default for less is not the right way to do it. I remember that some ebuild was updated recently which caused man output to be screwed up until I ran etc-update and used some changed configuration file, but I can't remember which one it was; I suspect there is a connection.
I had this problem and it seems when I downgraded sys-libs/ncurses from 5.3 to 5.2-r7 the problems with less went away.
*** Bug 14601 has been marked as a duplicate of this bug. ***
*** Bug 14942 has been marked as a duplicate of this bug. ***
I'm sorry, downgrading ncurses fixed the problem only some of the time. I should have tested more before comeing to that conclusion.
Bumped to -r2, and added '-R' until this can be resolved in a better way (groff side ?)
