[PATCH V2] progress: add output-prefix for GUI clients

[Jason Harris]

On Nov 6, 2011, at 7:11 PM, Matt Mackall wrote:

> On Sat, 2011-11-05 at 07:12 +0100, Jason Harris wrote:
>> # HG changeset patch
>> # User Jason Harris <jason at jasonfharris.com>
>> # Date 1320467623 -3600
>> # Node ID 6e27ea968dd0110eb378b5512fe64cac63dd36e7
>> # Parent  dc9d0189f60e6d216e79bbc162525b1d0324752c
>> progress: add output-prefix for GUI clients
>> 
>> For GUI clients which use the progress extension, the progress gets
>> reported on stderr and so to differentiate progress from errors it is
>> convenient to be able to specify a prefix before any progress reporting.
> 
> This doesn't fit very well with my vision of how this should be done.
> 
> First, GUI clients (or basically anything that automates against the
> command line) should be setting HGPLAIN.

I already *absolutely* need to set HGPlAIN to 1 when calling Mercurial
from MacHg.


> This keeps things like random
> extensions and aliases from breaking them. This includes color and the
> progress extension.

Yes it keeps a lot of stuff from breaking in MacHg. Having HGPLAIN on is
critical for MacHg.


> Second, when the progress extension is not enabled, progress messages
> are generated in a fixed format on _stdout_, but only with --debug:
> 
> http://www.selenic.com/hg/file/afc02adf4ded/mercurial/ui.py#l683

Ahh... But then I am faced with the same problem which I / we use HGPLAIN to get
around in the first place. Authors may from time to time decide to print more or
less information when --debug is used. Thus, MacHg would then have to know about
all of this debug information and account for it. So having --debug enabled is
bad from a GUI writers perspective in that unexpected things might crop up,
which is *exactly* the reason we GUI writers will use HGPLAIN in the first
place.

(Eg something like:
  hg clone --debug https://bitbucket.org/mirror/mercurial-crew
produces a ton of data that would have to be recognized and stripped out...
And that is only for clone let alone the other commands...)

So GUI writers will in general not use --debug I would think, since we want as
stable and predictable an interface as possible. (At least I don't use --debug.
I just checked and it doesn't from very simple grepping look like thg uses
--debug by default, and murky doesn't use it either but it has not had much tlc
in a good while. I haven't checked source tree... or other tools like
mercurial-eclipse, etc.)


> This should generally be preferable from the tool standpoint:
> 
> - if you want to ignore it, it's off by default
> - if you want to display it, it's in a fixed format for parsing

There are 3 problems with this:
(i) picking out the progress output from the normal standard output could be
quite hard, eg sometimes the progress extension has some white space in there
from memory, etc. (It looks like the debug version there would not have any
whitespace in it though... but there is a *ton* of debug information.)
(ii) Sometimes the output on stdout is huge. Eg a status command of a multi gig
repository is huge, thus instead of the GUI being able to handle a single chunk
of data which is our "answer" we would have to introduce streaming and
examination of the stuff on stdout and start trawling through it *as* it comes
out for progress information which would in general degrade performance and
be difficult / unstable  (although it might be technically possible)
(iii) To be sure we were not mixing any debug information with actual output I
would likely introduce a debug-prefix option in any case to prefix the debug output
and make it easy to parse out which bits are progress / debug and which bits are
the actual answer. And this prefix is the exact thing this patch adds in the
first place to the progress extension!

Moreover this two line patch (for the progress extension) of adding the option
"output-prefix" is really simple and is completely independent of any of these
issues. It just adds a prefix to the output of the progress. All these other
details of how GUI writers use it has nothing to do with this patch whatsoever.

I have already been using the progress extension in MacHg for quite some time
and it works well. The one case this patch fixes is when there is error's *and*
progress output. Previously sometimes some whitespace or single numbers would be
ascribed wrongly to the error message after stripping out the obvious progress
bits... See my fix using this here:
https://bitbucket.org/jfh/machg/changeset/fcac83fc48ae

Cheers,
  Jas