emacs interface for darcs (http://joyful.com/darcsum)
#1Darcsum hangs on record and no possibility to investigate why
I regularly have a record hanging, and since darcsum does not use an emacs buffer to communicate to darcs, I have no chance of fixing the problem. How can I observe the communication and see why darcs is hanging (probably waiting from some question to be answered that darcsum is unprepared for)?
The developer notes linked from the home page discuss this a little. Set the variable
darcsum-debugto true (M-x set-var, darcsum-debug, t) and you should get enough debug output to see which darcs output is confusing darcsum. (C-h e to see it all).Correction: M-x (setq darcsum-debug t)
I have finally figured out this bug! It is due to a change in darcs' handling of the '--quiet' switch. When using an older darcs (version 2.5.2) this bug does not appear: darcsum-record does not hang. Using a more recent version, however, 'darcs record --quiet' does not issue the final message "Finished recording ..." and so the process filter is left waiting.
I have patched darcsum to leave out the '--quiet' switch when calling 'darcs record', while leaving it in for all other subcommands. See my fork of darcsum (user: greglud).
Also in my fork are a few more (mostly cosmetic) enhancements to darcsum for your consideration.
Thanks a lot!
Which darcs versions is darcsum compatible with, after this patch ?
This is an instance of darcsum's biggest problem: it depends tightly on darcs' command line UI, which makes it fragile (and, as currently implemented it is not even able to detect the problem to give an error, instead it just hangs).
I've tested it successfully on versions 2.5.2, 2.8.0, and 2.8.3. I suspect anything inbetween should be fine as well. (I don't have a linux binary for the latest release 2.8.4)
I've merged your fix relating to this bug, and the UI enhancements. Looks great!
Here are the developer notes mentioned above, in case you find time to look more at this:
*** don't hang on unexpected darcs output Symptoms: the darcsum buffer fails to update within the expected time, the next operation fails due to _darcs/lock still present, the darcs process is found to be still running but idle. Workaround: kill the process manually, also remove the lock file if needed, and repeat the operation with darcsum-debug enabled to see what caused the problem. Cause: using the process-filter mechanism to drive an interactive darcs session is fragile. Because data is received in random chunks it can't reliably distinguish incomplete data and data it can't parse.
