Matthieu Moy wrote: > Hi, > > There have been a lot of discussion on this list about the output > format of "bzr status", whether it's good or not...
We are currently discussing having some sort of mode where you will run a bzr process, such that you connect to it using stdin/stdout, and keep issuing commands into it, and it keeps replying to you. This would be designed as a machine parseable interface (possibly XML, possible RFC822, possibly newline delimited whitespace, possibly etc) Mostly likely it will be configurable how you will talk, with maybe 2 reasonable forms supported. This would actually be a start on having a real smart server, where it can be talked to over ssh, or possibly over cleverly formatted http POST messages (to a cgi script/bzr webserver). We are working on refining a spec for it right now. I'm not sure how everything will work out, but the Wiki page for it is here: http://bazaar.canonical.com/SmartServer I don't believe the specific output "bzr status" will change soon, since it is designed to be somewhat human friendly. However, we might end up with a "bzr --xml status" which would use the formatting code from the previous work, and still give you a simpler method of calling it. Right now we are doing some serious discussions about how things will turn out, so I can only give vague hints as to what has been discussed, and what seems like it sounds good. > > I should be able to implement a bzr-status into DVC rather soon, and > I'd like to know how much I can rely on the output format. (I gave up > with pymacs, not being able to do asynchronous calls is a blocking > problem, and up to now, I didn't have problem with the command-line > interface). I'm surprised they don't support async, but I guess that is life. You still would likely get better efficiency by keeping bzrlib loaded in memory and reusing it somehow. I also don't have a specific timeframe for any changes, just that it is likely to be a route that bzr goes (some of it possibly soon, probably before 1.0). John =:-> > > Implementing a parser for this format in Emacs-lisp is not a problem. > Internationalization can be a problem, but I can call bzr with > "LANG=C bzr ...". The only problem is that I don't want to hardcode > this format in my lisp code if it may change in the future, so if the > probability of a change is high, I'll write a python wrapper that has > a fixed output format. > > [ People not interested in DVC can stop here ;-) ] > > I think I'll implement bzr status in a way similar to what Xtla does > for M-x baz-lint RET : display in a buffer something that looks like > the output of "bzr status" (but after parsing it and rebuilding it so > that further manipulation is easier). Operations on a file entry will > apply to this file, and operations on a group name (modified:, > unknown:, ...) will apply to all the files in this group. > > The idea is to provide the user an interface similar to the command > line, so using DVC-bzr should teach the user how to use bzr, but it > also provides more features and an integration in Emacs. > > Thanks for your comments, >
signature.asc
Description: OpenPGP digital signature
