Possible issue with command server

Yuya Nishihara yuya at tcha.org
Tue Apr 22 15:14:55 UTC 2014


On Sat, 19 Apr 2014 15:05:20 +0300, Idan Kamara wrote:
> 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:
> > > 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.

It will be safer, but I want to find a different way.  The command server
isn't an extension, it should be able to avoid class wrapping technique.

> > > > > 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'

Possible, but still it needs to encode label in some way.  It can't send
'start label' until ui.write() or ui.write_err() is called.

    labels = [ui.label('foo', 'status.added'), ...]  # :: [str, ...]
    ...
    ui.write(labels[x])  # 'start label:...', 'foo', 'end label:...'

And labeled text can be joined.  My pipeui extension can't handle this case:

    # http://selenic.com/repo/hg/file/d924e387604f/mercurial/commands.py#l1062
    rev = str(ctx.rev()).rjust(31 - encoding.colwidth(tag)...
    labeledtag = ui.label(tag, label)
    ui.write("%s %s%s\n" % (labeledtag, rev, notice))

We could have control channel, but I don't think ui.label is usable for it.

Regards,



More information about the Mercurial mailing list