#153576 Search is broken on very long lines

Package:
less
Source:
less
Description:
pager program similar to more
Submitter:
"Matt Zimmerman"
Date:
2005-07-18 03:53:36 UTC
Severity:
normal
#153576#5
Date:
2002-07-19 14:56:52 UTC
From:
To:
To reproduce:

perl -e 'print "\n", "junk" x 1000, "goodness"' |less +/goodness

The result is that the first line on the screen is the beginning of the
long 'junk' line, and 'goodness' (the target of the search) is well past
the bottom of the displayed screen.  This makes the search function
effectively useless in files with many very long lines, since the user
must then visually scan a large number of screens of text in order to
find the actual match.  less should arrange for this line to be
immediately visible when the search succeeds.

I have confirmed that this bug also exists in less 374, but not in 358.
#153576#8
Date:
2002-07-20 16:54:32 UTC
From:
To:
----- Forwarded message from Matt Zimmerman <mdz@debian.org> -----

Subject: Bug#153576: Search is broken on very long lines
Reply-To: "Matt Zimmerman" <mdz@debian.org>, 153576@bugs.debian.org
From: "Matt Zimmerman" <mdz@debian.org>
To: "Debian Bug Tracking System" <submit@bugs.debian.org>
Date: Fri, 19 Jul 2002 10:56:52 -0400
Sender: Matt Zimmerman <mdz@poseidon>

Package: less
Version: 376-2
Severity: normal

To reproduce:

perl -e 'print "\n", "junk" x 1000, "goodness"' |less +/goodness

The result is that the first line on the screen is the beginning of the
long 'junk' line, and 'goodness' (the target of the search) is well past
the bottom of the displayed screen.  This makes the search function
effectively useless in files with many very long lines, since the user
must then visually scan a large number of screens of text in order to
find the actual match.  less should arrange for this line to be
immediately visible when the search succeeds.

I have confirmed that this bug also exists in less 374, but not in 358.

----- End forwarded message -----
#153576#13
Date:
2002-07-22 19:29:38 UTC
From:
To:
I've looked into this a little further, and the problem seems to be related
to the dynamic expansion of linebuf.  After much trial and error, I found
that the problem only occurs if the buffer is expanded during forw_raw_line.
Disabling the expand_linebuf() call in that function, and acting as if it
failed (reverting to the 358 behaviour), causes (this particular
manifestation of) the problem to vanish.

In fact, it's starting to look as if this was an accidental feature.  The
highlighted pattern match would always be on the screen because it was
broken up into 1024-character lines, which (for text data) will always fit
on an 80x25 terminal.  So I guess this becomes a feature request, "please
make sure that the match is on the screen after a search".