monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Workspace commands and automate/stdio


From: Thomas Keller
Subject: Re: [Monotone-devel] Re: Workspace commands and automate/stdio
Date: Tue, 10 Jul 2007 13:01:47 +0200
User-agent: Thunderbird 2.0.0.4 (Macintosh/20070604)

William Uther schrieb:
>> a) implementing the commands means code doubling, and that also means
>> double maintenance
> 
> Not necessarily.  I was looking at merging the CMD and CMD_AUTOMATE
> macros.  Even command needs to be in automate anyway, right?  There
> would be an extra bool that lets you know which you're in, for those
> situations where you need to know.  All output would be sent to the
> output stream, and that would be connected to stdio when a command
> is called normally.
> This gets almost to the point where we should just make --automate a
> global option.
> We could keep the automate command group for commands that we don't
> expect normal
> users to use.  Some other commands could probably be moved in there too:
> "mtn db execute"?

Hrm... my fear is if we mix "automate" commands under the normal ones we
loose track of the interface and its stability. Are there other opinions
on this point?

>> b) there is no agreement yet how the output should look alike in an
>> error case, especially for stdio
>>
>> Monotone uses a couple of global macros which error out well-defined if
>> something went wrong and this even works for the stdio ostream. However,
>> what you get as error message is still the same one a normal user would
>> get. You could start stdio or any other mtn subprocess with LANG=en,
>> still, if one of those english messages would change (spelling, etc.),
>> any automate command wouldn't take notice of it and you wouldn't see it
>> through the interface_version number either.
> 
> Hrm.  This is more of an issue...
> 
> Is it possible to subvert the translation system with a LANG=MTN_AUTO when
> we're running a command in automate mode?  We could then provide an
> "automate" translation which could be kept consistent.
> 
> I don't know enough about the translation system to know how this would
> actually work.

I don't know if gettext would screw up if it sees a non-existent
language, I guess we have to try that out.

> This is the problem holding up my nvm.lua_cmds branch at the moment.

Translations or missing workspace commands for automate?

Thomas.

-- 
only dead fish swim with the stream: http://thomaskeller.biz/blog
Am Anfang war das Wort: http://www.schäuble-muss-weg.de




reply via email to

[Prev in Thread] Current Thread [Next in Thread]