Comment 10 for bug 353370

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.