-J is taking up 2 columns not 1

[khwilliamson]

No description provided.

[khwilliamson]

I upgraded to Ubuntu Mate 20.04, and suddenly data that fit into a particular width started overflowing onto the next line. There were two initial columns with -J instead of 1. Further I note that I am using -W, the docs say it creates a status column, but without the -J it doesn't.

Here is my LESS environment variable value:
LESS="-X -i -W -J -F -R -h7 -a -s -M -e -PM?e(END)?x Next file: %x.:--More--?n?f%f.?m %i of %m. .(?pB%pB%:%lB lines shown.)."; export LESS

[gwsw]

Yes, this was changed in 0a150b3, after the status column was enhanced to show mark letters. It could be confusing to have a mark letter immediately next to the first letter of the text, so a space was added to separate them.

[khwilliamson]

I delayed responding because I was trying to come up with the most persuasive argument to overcome what I envisioned would be the standard dismissive circle-the-wagons attitude that seems so prevalent these days. But I couldn't. But I do think something should be said. So here goes.

In short, this is a breaking change. After decades of stability in a command that is all about geography, this commit changed that geography by lowering the space available to the caller. It did so by adding what is essentially a spacer column; the man page is essentially silent about this, mentioning only a status column. I can see why some might want a spacer column, but my assertion is that it should not be the default, but an option, say -2, so you could say -J2 to get it. I personally don't think I would be unduly confused by the lack of a spacer, so I wouldn't use this option, and this change breaks code that I have used for decades that was carefully tailored to fit in a particular width.

But it's not only me. There are many programs that wrap text lines that won't fit into the available window width. The open source project I work on has several. Some of these create static documentation at the time the code is compiled. They don't know the width the final window things will be displayed in will be, so they assume 80 columns, which is the minimum industry standard width. I checked, and my latest Linux distro has that as a standard width. Those wrapping programs want to use space as efficiently as possible, and they know from decades of history that pagers can reserve a column for themselves, and so they assume they have 79 columns available, and pack things up so that they use as much of those as possible, but no more. These are now broken on 80 column wide windows, which remember has been an industry standard for a very long time.

And the programs that dynamically wrap at display time by querying the window's actual width assume that they have to leave a single column for the pager as a worst case; they are also broken.

And my project's documentation has many lines that are to be output verbatim, generally input and output examples of what happens when the program is run. These have been laboriously crafted to fit in at most 79 columns. Otherwise, they would either be truncated when displayed in an 80 column window, (again, the industry-standard minimum width) or would wrap to the next line in the middle of a word, making the display much less legible. To prevent this from happening, we have a script that checks our documentation for this kind of overflow so that someone doesn't unwittingly create hard-to-read documentation. I ran that script with one less column available, and there are many cases where that is exceeded. The bottom line is this commit will cause me to laboriously narrow these.; I'd rather be fixing bugs and enhancing our functionality.