ProgressBar during bzr branch

[duchier at ps.uni-sb.de]

The function (bzrlib/progress.py) _supports_progress is used to
determine whether to use a TTYProgressBar or a DotsProgressBar.

This function returns False when run under Emacs and that's
unfortunate because the Emacs shell is perfectly capable of handling
the terminal hackery emitted by the TTYProgressBar.  Worse yet, the
DotsProgressBar induces a significant slow down in all cases.

Here are some timings on my laptop, where I invoked:

	brz branch bzr.dev bzr.tmp

under various shells and for _supports_progress returning either False
or True:

+-------------------------------------+--------+------+
| SHELL                               | False  | True |
+-------------------------------------+--------+------+
| xterm                               |   18.8 | 13.8 |
| emacs subshell (font-lock-mode on)  | 1m34   | 13.8 |
| emacs subshell (font-lock-mode off) |   26   | 13.8 |
+-------------------------------------+--------+------+

The very bad performance of the emacs subshell with font-lock-mode
turned on is due (I believe) to a large extent to the fact that the
dots are all printed on one very long line.  This causes repeated
rehighlighting of the line every time a dot is appended.  Furthermore,
the dots-based output is just more stuff to display and is thus
inherently slower in all cases.

Instead of turning off TTYProgressBar selection with this test:

    if os.environ.get('TERM') == 'dumb':
        # e.g. emacs compile window
        return False

I would prefer to remove this test altogether and have an option
(e.g. --dumb) that selects the DotsProgressBar in that case.  I am
willing to provide a patch.

What do you guys think?

Cheers,

--Denys