On Tue, 18 Oct 2016 15:15:35 +0100, Barry Scott wrote:
> > On 18 Oct 2016, at 14:11, Yuya Nishihara <y...@tcha.org> wrote:
> > 
> > On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
> >> There are 2 reasons to have the cbout and cberr call backs. For a 
> >> push/pull that
> >> does not prompt it provides the GUI with progress information clearly 
> >> marked as
> >> normal, cdout, and error, cberr. The output is also timely, no need to 
> >> wait for the
> >> command to complete.
> > 
> > In that case, it'd be nice if we have a generic callback interface like your
> > another patch. Progress messages aren't limited to push/pull commands.
> Oh I guess you are thinking of clone(), that will be long running and 
> produces progress on the command line.
> I can add that to the patch. Do you think I missed another that is long 
> running, has progress and is silent in
> hglib?

Maybe some of these:

archive, bundle, identify (of remote repo), incoming, outgoing,
summary (with remote=True), update (involving subrepo pull)

If we had verify(), it would also be slow.

>  I do not think that the setprotocol pattern works for the command output.
> Given only some commands can usefully return output and error text it seems 
> better to pass in
> the call backs if you want that information. It is then very clear which 
> command the output and error
> belongs to.
> Many hglib commands want to process the output to return pythonic results 
> from hglib to the user.
> Other commands have no output and raise an exception with error text if they 
> fail.
> Both these seem to be fine already.

Problem isn't that simple. You can run .log('outgoing()') for instance, which is
slow enough to show progress and sometimes needs a password prompt. That's why
I want to separate data and status messages at channel level.

> >> When a prompt event happens I found that I cannot rely on figuring out what
> >> the last prompt was without a timeline of calls to cdout and cderr.
> > 
> > or inspect the last lines of both out/err channels? Anyway it's unreliable 
> > to
> > read the prompt line, so we'll need a better channel protocol in future.
> > 
> >> For example cdout gets the “user:” prompt but cderr gets the “password:”.
> >> (Why is “password:” sent to stderr? Bug? Feature?)
> > 
> > That is considered a feature of hg, but isn't nice in command-server 
> > session.
> > I made an extension to send more information over the pipe. It's just a 
> > hack.
> > My current plan is to add an option to send prompt, progress, and status
> > messages to a separate (e.g. 'C'-ontrol) channel.
> > 
> > https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/util/pipeui.py 
> > <https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/util/pipeui.py>
> What I really want to see is a get-credentials call back, lIke subversion API 
> has.
>      username, password = cbgetcredentials( URL, realm, username=None )
> Then I do not need to parse out for messages the URL, I can prompt the user 
> once for
> both username and password. I do this with this patch and a lot of extra 
> logic in my GUI.

Yeah, I want it.

For a temporary workaround, I think we can simply extend prompt().
Mercurial-devel mailing list

Reply via email to