Robert Widhopf-Fenk <[EMAIL PROTECTED]> writes: >> 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 ...
See my answer to John in the same thread. That's a different problem. I think the "bzr service" should solve the problem, just like emacsclient does for Emacs. To use bzr from Emacs, we need two things: a) A way to call bzr and to get its output, and b) a way to interpret its output. For example, Pymacs provides a good solution for a) (it keeps a Python interpreter loaded), and a ready-to-use solution for b) (there is /already/ a generic parser provided, you get lisp structures directly). My current solution (launch a new process for each operation) has this latency problem for a), and the fact that you have to write your own parser for b). My claim is that regarding b), and at least to parse the output of "status", the parser is not the bottleneck (both in terms of performance and manpower). >> 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? 'course not. I'm not crazy ;-). (but I also rarely have spaces and non-ascii characters, so I'm not a good example) -- Matthieu
