https://bugzilla.novell.com/show_bug.cgi?id=244791#c16
L. A. Walsh changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |REOPENED
Info Provider|suse@tlinx.org |
--- Comment #16 from L. A. Walsh 2007-08-02 23:49:22 MST ---
I am not able to reproduce the original behavior/difference.
I don't know why, but the upgrade to 10.2 "erased" the previously working
behavior. I thought I tested 10.1 and it worked, but as you mention, the
packages between 10.1 and 10.2 are the same.
Either I had an unknown version of less installed, or (as you noted above),
I changed the order of the LESS options. (from -rR to -Rr)
The program (less) overloads 1 variable to hold the state of "r-off", "-r" or
"-R". While it isn't stated, only the last "r" switch (-r or -R) takes effect.
I'm guessing, but this behavior must have resulted in the confusion, somehow.
(They should be orthogonal options, from my point of view -- not different
values of 1 common switch -- that's confusing, but ...whatever...).
I'm enclosing a patch to 2 files that fixes the problem -- sorta. Ideally,
one could have both switches -- but I didn't separate them in this patch.
Instead, I simply removed the 3 places in the code where "-r" throws away the
line position information so its function will most closely match the man page.
Manpage (as quoted above):
when the -r option is used, less cannot keep track of the actual
appearance of the screen ....various display problems may
result, such as long lines being split in the wrong place.
------
As stated, the "-r" may cause long lines to be split "needlessly" (in wrong
place), WITH the attached patch.
As the code stands in 10.2, it conflicts with the manpage: a long line
will never be split since it doesn't keep track of column information -- the
only thing that will happen is that the line will wrap and less will scroll
lines off the screen (as demonstrated with above test cases). I have a feeling
"-r" used to be the way it is now (at least from reading the manpage), but the
column tracking was removed.
I.e. with column tracking enabled (and assuming no control characters
reposition the cursor abnormally), the user may end up with lines split on
screen too early and less may not make full use of the screen.
With the code disabling column tracking entirely (as it is in 10.2), less will
lose information off of the screen on long lines. I perceive the loss of
information to be worse than "insufficiently optimized use of screen" (with no
text lost).
This patch does remove the ability to "ignore columns completely" -- which
could have a use in viewing raw screen dumps with positioning information in
them. This is a useful function as well, but less is more designed to display
text files -- not binary files.
Ideally the ability to display raw characters could be uncoupled from screen
position accounting. This would likely require another option. Then a user
could specify "raw" display but keep ANSI-escape-code-position tracking (the
-R option).
Two files attached, one the patch to the source distribution file "less.c" to
NOT disable column tracking, and a diff to the spec file (bumping version
from 394-32 to 394-32a).
This may "qualify" this as an "RFE" (Request for Enhancement)...
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.