On Wednesday, 19 October 2016 00:29:52 BST Yuya Nishihara wrote:
> 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.

I see why you want to set the call backs globally. I'll do that.

I think I can also have the solution for hglib.clone() and hglib.init().
I need to test more to be happy with those changes.

> > >> 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().

What do you have in mind? I'm not seeing an easy win here.

Barry

_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to