--header renders -S toggling impossible (v643)

[cohml]

Problem description

When the --header option is passed, lines are wrapped by default but cannot be unwrapped. -S no longer has any effect.

Steps to reproduce

First define a simple utility function. This function will output text virtually guaranteed to exceed the dimensions of your screen. We will pipe this text into less with various options.

function make_long_lines() {
    local start=0
    for ((i=$start; i<500; i++))
    do
        echo {$start..$((start + 500))}
        start=$((start + 1))
    done
}

With no less options passed, -S toggles wrapping on and off as expected:

make_long_lines | less

With --chop-long-lines passed, lines begin chopped, but -S still toggles wrapping, as expected:

make_long_lines | less --chop-long-lines

With --header passed, lines also begin chopped, but -S does not unchop them. -S now seems to have no effect. This is NOT expected:

make_long_lines | less --header=1

It's unclear if this is a bug or by design. But if it's not a bug, this limitation of --header is not documented on the man page:

❯ man less | awk '/--header/ {if (++count == 2) header_entry=1} header_entry; header_entry && /^$/{exit}'
       --header=N[,M]
              Sets the number of header lines and columns displayed on the
              screen.  The value may be of the form "N,M" where N and M are
              integers, to set the header lines to N and the header columns to
              M, or it may be a single integer "N" which sets the header lines
              to N and the header columns to zero, or it may be ",M" which
              sets the header columns to M and the header lines to zero.  When
              N is nonzero, the first N lines at the top of the screen are
              replaced with the first N lines of the file, regardless of what
              part of the file are being viewed.  When M is nonzero, the
              characters displayed at the beginning of each line are replaced
              with the first M characters of the line, even if the rest of the
              line is scrolled horizontally.  If either N or M is zero, less
              stops displaying header lines or columns, respectively.  (Note
              that it may be necessary to change the setting of the -j option
              to ensure that the target line is not obscured by the header
              line(s).)

Version

❯ less --version
less 643 (PCRE2 regular expressions)
Copyright (C) 1984-2023  Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Home page: https://greenwoodsoftware.com/less

[polluks]

By the way I don't understand your function, it doesn't make long lines, just 8-10 characters

$ make_long_lines | awk '{++a[length()]} END{for (i in a) print i, a[i]}'
8 10
9 90
10 400

[cohml]

Very strange. Maybe it's a portability thing? It works for me as I described.

❯ make_long_lines | wc
     500  250500  996895
❯ make_long_lines | awk '{++a[length()]} END{for (i in a) print i, a[i]}' | head

1944 1
1945 1
1946 1
1947 1
1948 1
1949 1
2000 1
2001 1
2002 1
2003 400

Anyway, here's something else which should yield long lines and hopefully be reproducible by everyone:

curl -s https://www.gutenberg.org/cache/epub/15143/pg15143.txt \
| perl -pe 's/\r\n/ / unless /^\r$/ || eof' | sed -n 100,200p | less

This command should

1. pull a plain text novel off of Project Gutenberg, then
2. transform it so each line contains a full paragraph, then
3. pull out 200 lines from the middle (the frontmatter is mostly short lines).

Again the point is just to give you some guaranteed long text to test less with.

[gwsw]

This is intentional. When there is a header line, you generally want to be able to see the content that is vertically aligned with the fields in the header line. But if the text is wrapped, this alignment is disrupted by the wrapped ends of lines. My experiments indicated to me that this would just not be useful. There are also some technical issues that would require a fair amount of coding to solve, and since the end result seems less than useful, it didn't seem worth it. I will update the man page to document this behavior.

[cohml]

I see. That's unfortunate to hear.

Rather than designing the perfect header to rule them all, would you entertain implementing a --dumb-header or something which neither interferes with -S nor attempts to beautify the alignment? Then perhaps the user can choose how much they care depending on the text they're paging? If not, I suppose you can close this issue as not planned.

I'm not sure how severe the non-alignment issue is from a usability standpoint. But line wrapping/unwrapping is so essential, I'd hate for it to render any kind of header impossible.