On Mon, Apr 14, 2014 at 7:51 PM, Yuya Nishihara <yuya at tcha.org> wrote:
> On Sun, 13 Apr 2014 16:11:04 +0300, Idan Kamara wrote:
> > On Sun, Apr 13, 2014 at 3:35 PM, Yuya Nishihara <yuya at tcha.org> wrote:
> > > On Sun, 13 Apr 2014 13:07:36 +0300, Idan Kamara wrote:
> > > > On Sun, Apr 13, 2014 at 7:01 AM, Yuya Nishihara <yuya at tcha.org>
> wrote:
> > > > > On Sat, 12 Apr 2014 16:53:18 -0400, Matt Mackall wrote:
> > > > > It's reported as
> > > > > http://bz.selenic.com/show_bug.cgi?id=3161
> > > > >
> > > > > FYI, I wrote a little extension for TortoiseHg to capture ui
> labels and
> > > > > progress.
> > > > >
> > > > >
> > >
> https://bitbucket.org/tortoisehg/thg/src/a859f999ce68/tortoisehg/util/pipeui.py#cl-222
> > > >
> > > > Looks like you're solving a couple of issues with the protocol there,
> > > > any reason you haven't submitted those? We can at least do something
> > > > about getpass.
> > >
> > > Ok, I'll try to fix ui.getpass(), probably by using isatty(fin) ?
> > >
> >
> > Do you mean falling back to regular stdin if isatty (or ui.interactive)
> ==
> > False? I think most clients deliberately set that config to True so input
> > is allowed.
>
> Something like
>
> if self._isatty(self.fin):
> self.write_err(...)
> getpass.getpass('')
> else:
> self.prompt(...)
>
> _isatty() isn't affected by ui.interactive=True, so this change will be
> okay
> for commandserver client. But it might break general command-line use
> case.
>
Yeah, that seems to be a bit risky. I think overriding getpass in a
custom ui class might be safer.
> > > > Changing the message format in the manner that you have is probably
> > > > not going to work for existing clients but we could perhaps add
> another
> > > > channel for labels?
> > >
> > > It won't be easy because arguments of ui.write() can be pre-labeled:
> > >
> > > msg = ui.label('foo', 'status.added')
> > > ui.write(msg)
> > >
> > > And if I understand it, commandserver avoids extending ui class.
> >
> > I think it was more because we had better ways of solving issues
> > around it, but it might make sense to do it here.
>
> Hmm, but I still don't think labels can be fit to separate channel because
> they are attributes of payload. It might be possible, but IMHO, is hard to
> manage.
We could translate a call to ui.label to 3 writes:
ui.label('foo', 'status.added') ->
control channel: 'start label: status.added'
output channel: 'foo'
control channel: 'end label: status.added'
>
> -- server --
> # encode label into msg
> msg = ui.label('foo', 'status.added')
> # split encoded label to write to flabel and fout channels
> ui.write(msg)
>
> -- client --
> case flabel:
> curlabel = data
> case fout:
> if curlabel:
> ...
> else:
> ?
> handle(data, curlabel)
> curlabel = nil
>
> Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140419/fc970e6e/attachment-0002.html>