From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?S=C3=A9bastien_Vauban?= Subject: Re: [Babel] No output returned if just one command is failing Date: Thu, 02 Dec 2010 21:27:31 +0100 Message-ID: <80fwufudho.fsf@missioncriticalit.com> References: <80eia1ondv.fsf@missioncriticalit.com> <87r5e1ftxl.fsf@gmail.com> <80sjyhjz0b.fsf@missioncriticalit.com> <87d3pkialo.fsf@gmail.com> <80d3pkuqm8.fsf@missioncriticalit.com> <87sjygf3ym.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Dan and Eric, Dan Davison wrote: > S=C3=A9bastien Vauban writes: >> Dan Davison wrote: >>> S=C3=A9bastien Vauban wrote: >>>> "Eric Schulte" wrote: >>>>> I don't forsee adding partial results insertion both because >>>>> >>>>> - it would add a good deal of complexity to the code to insert results >>>>> part-way through a run >>>> >>>> I can't comment on this, of course. >>>> >>>>> - the current behavior of only inserting results on a fully successfu= l run >>>>> is reasonable and is probably more obvious (at least to me) than >>>>> inserting partial results >>>> >>>> Being fond of Babel, I'm using it always, everywhere. I prefer: >>>> >>>> 1. typing my shell commands in an Org buffer, >>>> 2. evaluate the block, >>>> 3. get the results automagically inserted in the buffer, >>>> 4. (eventually, version the whole file for later comparisons when upda= ting >>>> the code), >>>> 5. export the whole to HTML and/or PDF. >>>> >>>> The current behavior, even if totally respectable and defendable, inhi= bits >>>> such a way of working: if you write (or update) a shell code, and don'= t see >>>> (more or less) the same things as the ones you would see in a shell bu= ffer, >>>> then you can't use such an Org buffer -- as long as one command fails. >>>> >>>> I don't especially want you to change your position, but I'm explainin= g the >>>> "negative" consequences for me. >>> >>> I definitely have some sympathy with your request. On two occasions I'v= e had >>> to manually make this change just to carry on working. >>> >>> But do we actually change babel in this direction? [...] >>> >>> The thing is that babel currently has a clear, simple, rule which says:= if >>> there's an error, the result is the elisp value nil. >>> >>> Eric and I have discussed in the past whether there should be any change >>> in this direction. The idea of a :debug header arg has been floated, >>> that would allow this behavior. Or tacking stdout on to the error >>> output. I tend to think that the behavior you request does need to be >>> made available, somehow, whether by default or not. >> >> If find this conclusion a bit contradictory with the fact that you even = needed >> it yourself. > > Hey Seb -- you mis-read me there. I was agreeing with you that the > behavior should be made available. Yes, it seems I did add a implicit *not* in your last sentence... My impressions are that shell blocks may be a totally different beast from = the other source blocks. If so, it could legitimate a slightly different treatm= ent (or default set of options). All of this discussion once again turns around the handling of errors, and = the two streams (stdout and stderr). Aaaah, here's well a proof it's different from the rest (languages such as emacs-lisp), at least in their classic usa= ge? My dream would be to be able to write, debug and use code blocks from Org, = and only Org. Not be forced to use the shell because some unknown condition make them return an error. Note: Can you explain me what's an error in the case of a sh block? See my previous post(s) of today. Thanks... Maybe once acceptable solution would be to output everything as it is in the terminal, mixing both streams. A possible dream of mine could maybe even become true here: the possibility= to clearly distinguish both streams by coloring them differently in the Org results: for example, all lines from stdout in black, all lines from stderr= in red... Though, I understand Eric's fears of problems for chained blocks execution. But, anyway, what else would you expect than what occurs in a terminal? Why should it be different? Best regards, Seb --=20 S=C3=A9bastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode