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