Progress extension, windows and carriage return

Martin Geisler mg at aragost.com
Mon Apr 26 03:14:11 CDT 2010


Patrick Mézard <pmezard at gmail.com> writes:

> 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?

I think it's fine to cut it off at 79 characters. In a Gnome Terminal,
the cursor becomes visible when the line is 79 characters wide, at 80
charactersr the cursor is somehow just outside the window. In xterm and
Eterm I see the cursor with both 79 and 80 character wide lines.

I don't know if it's related, but I use Zsh which has a "right prompt"
as well as the normal "left prompt". The right prompt also stops at
position 79 instead of going all the way to position 80.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list