Progress extension, windows and carriage return

[Patrick Mézard]

Right now, mixing hgsubversion with progress on windows is a bit annoying because progress causes empty lines to be displayed before converted status lines. I thought it was related to termwidth() but in fact this comes from a difference in the way unix consoles and cmd.exe deal with carriage return. Here is a test script mimicking how progress works:

------------------
import sys, os, time
# set stdout to binary mode on windows, not shown here

for j in xrange(3):
    sys.stdout.write('%d\n' % j)
    for i in xrange(3):
        sys.stdout.write('\r' + str(i)*80)
        sys.stdout.flush()
        time.sleep(0.5)
    sys.stdout.write('\r' + ' '*80 + '\r')
-------------------

On unix, the lines of 80 1, 2 and 3 are displayed successively, overwriting each other, then deleted by the line of spaces. This is the expected behaviour.
On windows, the lines of 80 1, 2 and 3 are displayed but never deleted, so everything is written on screen and stay there. If I change 80 into 79, I get the same behaviour than on unix (my console width being 80 columns).

I do not have other command line tools doing progress bars on windows so I cannot really check if they manage to fill the whole line. A quick search did not bring anything relevant.

So, we could add a specific property in util.py like countcarriagereturninconsoleline() and override it in windows. Or we can just sacrifice the last column unconditionally:



diff --git a/hgext/progress.py b/hgext/progress.py
--- a/hgext/progress.py
+++ b/hgext/progress.py
@@ -147,7 +147,7 @@
         sys.stderr.flush()
 
     def width(self):
-        tw = util.termwidth()
+        tw = util.termwidth() - 1
         return min(int(self.ui.config('progress', 'width', default=tw)), tw)
 
     def progress(self, orig, topic, pos, item='', unit='', total=None):


Any opinion?

--
Patrick Mézard