On Saturday, November 5, 2005 at 13:11:00, Matthieu Moy wrote:
> Robert Widhopf-Fenk <[EMAIL PROTECTED]> writes:
>
> > On Friday, November 4, 2005 at 16:58:24, Matthieu Moy wrote:
> >>
> >> Implementing a parser for this format in Emacs-lisp is not a
> >> problem.
> >
> > We might also consider to write a bzr plugin providing the
> > output in an emacs readable format, i.e. a list:
> >
> > ((modified ("FILE1" "FILE2" ...)
> > (renamed ...)
> > ...))
>
> Yes, but the effort to write this output format is comparable to the
> effort to write the parser for the current "bzr status" in elisp. If
> I can rely on the output of "bzr status", then I'll use
> it. Otherwise, /if/ I have to write my own wrapper script for status
> in bzrlib, then, I'll probably opt for a lisp output, yes.
>
> Otherwise, the parser will be stg like
>
> (while ...
> (cond ((looking-at "^\\([^ ].*\\):")
> (action regarding a group name (match-string 1))
> ((looking-at " +\\(.*\\)$") foo
> (action regarding file name (match-string 1)))
> (t (error "...")))))
I tried just for fun
bzr get http://www.robf.de/Hacking/bazaar/bzr-emacs/
but it is certainly more code than in lisp ;-)
> Performance-wise, that's clearly not the bottleneck.
Not elisp, but the latency to start multiple bzr commands is
IMHO kind of a bottleneck, at least in my tcsh completion code
it is kinda painful ...
> The only problem with bzr status now is for file names with '\n' in
> it, which would have to be escaped. Well, currently, bzr is buggy
> regarding newlines in filenames, and no one complained ...
Just wondering, do you have trees with such names?
Robert
