Lines cut off at 80 chars regardless of actual terminal size

[DanielBachran]

When using the pager plugin lines are cut off at a length of 80 characters even if the actual terminal size has a bigger size.

This can be observed when using a terminal with a size of e.g. 100x40 characters and running "bzr log --line" in the current branch of the pager plugin: the commit description of revision 9 is cut off at 80 characters.

I'm currently using the latest revision (revision 11) of the pager branch at: http://bazaar.launchpad.net/~luks/bzr-pager/pager/

[Lukáš Lalinský (luks)]

Plain "bzr log --line | less" has the same problem.

[DanielBachran (dbachran)]

When not using the pager plugin bzr recognizes the correct terminal size. (I don't have access to my linux box right now to check how "bzr log --line | less" behaves, though.)

Only when using the pager plugin, bzr seems to think that the terminal is 80 chars wide, as longer lines get chopped off with 3 dots at the end (which is done by bzr itself as I understand it).

Here on my windows machine at work I see no difference between "bzr log --line" and "bzr log --line | less", both without the pager plugin. But, as I stated above, I still need to validate how my linux box behaves.

[DanielBachran (dbachran)]

Hi again, I've tested the behavior on one of my linux machines just now and I agree: "bzr log --line | less" behaves the same as the pager plugin.

It's been some years since I've last tinkered with termcap and friends, so I don't know where the difference may be between bash running on windows/cygwin on the one side (where "bzr log --line | less" behaves correctly) and bash running on linux (where "bzr log -line | less" cuts off at 80 chars).

So anybody who's able to shed some light onto this is very welcome! Thanks in advance.

[Joke de Buhr (joke)]

bzr 2.0 on karmic cuts of at 80 chars as well:

  bzr help commands | less ## (no pager plugin installed)
  bzr help commands | more ## (no pager plugin installed)
  bzr help commands ## (pager plugin installed)

bzr seems to query the wrong number of columns.

[Lukáš Lalinský (luks)]

The best option would be to not truncate/reformat the output if stdout is not a terminal.

[Vincent Ladeuil (vila)]

It turns out that using an arbitrary large value for terminal width for no-ttys is a bad idea after all, it leads
babune (the test botnet) to generate *huge* log files (>1GB instead of ~3M) for the selftest runs.

[Matt Nordhoff (mnordhoff)]

Vincent Ladeuil wrote:
> It turns out that using an arbitrary large value for terminal width for no-ttys is a bad idea after all, it leads
> babune (the test botnet) to generate *huge* log files (>1GB instead of ~3M) for the selftest runs.

Bug #458741 (test failures with subunit) and bug #458743 (progress bars
spamming the screen with spaces or something) too.
--

[Vincent Ladeuil (vila)]

So relying on tty detection is not really an option as the rest of bzrlib really want a width to either
fill or truncate the output lines.
While truncated lines are not a problem with large width values, filled ones are.

Until we address the various usages of terminal_width(), I'll just revert the proposed patch.

As a poor workaround, if you set the COLUMNS environment variable if will take precedence over the 80 default value
used by bzrlib.

[Vincent Ladeuil (vila)]

See lp:~vila/bzr/353370-notty-no-term-width for broader solution that also address bug #62539

[Martin Pool (mbp)]

So to carry on from my comments in https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 it seems we are interested in at least these different types of "width":

1- The width at which text should be truncated to stop it from wrapping, which is used by eg log --line. If it's too short, you get this bug 353370; if it's too long the text will probably wrap which is fairly harmless. If in doubt, you should probably not truncate at all. When there is no terminal at all you probably don't want to truncate, but if you're going through a pager to a terminal you probably do want to use that width.

2- The width we should indent for right-aligned content. If we don't know the width of the terminal it would probably be ok to assume 80. In some cases this is combined with truncation and if we don't know the terminal width we should probably pad but not truncate.

3- The width of the screen you have to erase to redraw eg a progress bar. If this is too short, it's actually ok, as long as we consistently use the same amount - we'll just draw progress that doesn't cover the whole screen. If it's too long, it is a bit of a problem because the terminal will probably wrap and you get detritus down the screen. If there is really no terminal we're probably not going to draw progress bars, but if we think there is a terminal of unknown width it could be ok to assume 80.

[Martin Pool (mbp)]

... I'll also add in these cases that the only one where assuming unknown means infinite is #1.

Looking through the uses of terminal_width:

_help_commands_to_text: wants to wrap text, which is a bit like #2.

LineLogFormatter: truncates, case #1.

TextProgressView and TTYProgressBar: case #3 obviously, and also case #1 in that it truncates the pb text to fit.

show_pending_merges: calls in to LineLogFormatter, so also case #1.

report_test_start: wants to show the test name truncated to the terminal width and also show the outcome or time aligned to the right (#1 and #2).

I wonder if we should just handle this by eliminating case #1 altogether: show the whole first line of the log message, and rely on people putting a reasonably short first line, as for docstrings. But perhaps people have entered long single-line arguments to ci -m.