Sébastien Vauban writes: > Hi Eric, > > "Eric Schulte" wrote: >> Sébastien Vauban writes: >>> "Eric Schulte" wrote: >>>> Sébastien Vauban writes: >>>>> "Eric Schulte" wrote: >>>>>> Sébastien Vauban writes: >>>>>>> >>>>>>> 2. When the evaluation produces no output, but had well produced output >>>>>>> before, shouldn't Babel have to delete the previously written >>>>>>> results in the Org buffer? >>>>>> >>>>>> This is a good point. Currently Babel just quits if it receives a nil >>>>>> result, but I think you're right that we should replace existing results >>>>>> when a nil result has been returned. I'll add this as PROPOSED to the >>>>>> babel task list. >>>>> >>>>> I consider this kind of mandatory, for the sake of coherency, and to >>>>> really make use of Org-babel every time I want to run some shell commands >>>>> (and change them, eventually getting no results then). >>>> >>>> I've just pushed up a change that implements this behavior. >>> >>> From my point of view, it does not work yet. Take this example: >>> >>> With `:cmdline reg unknown', it produced the line with -21.91 EUR. Correct. >>> >>> Now, if I write `:cmdline "reg" unknown', I expect no output from Ledger, >>> and thus the results block to be removed. That's not the case. >> >> If ledger throws an exception then the result probably will not be replaced, >> however if ledger does return an empty result, then the existing result will >> be removed. > > What do you mean by ledger throwing an exception? Having a return code > different from 0? > Yes, that's exactly what I mean. > > For me, the result block should be removed in both cases: > - "exception" of ledger > - empty result of ledger > > Or, if not, then (even better): instead of simply removing the result block, > replace it with a sort of error message, saying that ledger's execution failed > and returned XXX as exit code. > This is what we used to do (insert the error output into the buffer as results), however we now treat error messages and STDOUT differently, and Babel /should/ notify you of error output and then abort the evaluation chain. > > Whatever the solution, we have to clearly be aware that the previous > results are now wrong, and that the new result is a failure or empty. > Agreed, this notification should be done through a pop-up buffer of the error output (however the previous results are retained because at least when they were generated they were not an error). Also, returning the error results could cause problems in the case of chained code blocks. I don't have a local ledger install, and I didn't implement the Babel ledger support, but I've made some changes to ob-ledger so that it now uses the general Babel external evaluation tools (which should raise errors as I've mentioned above). Could you give this patch (attached) a try and let me know if it improves the behavior you're seeing?