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
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
