From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Syntax of Org Babel ":results" header argument Date: Fri, 15 Mar 2013 10:54:16 +0100 Message-ID: <86mwu59eev.fsf@somewhere.org> References: <86li9v1nb0.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hello, As there was no reaction to this, I'd like to bump it up. At least, to either have a discussion on this, or a clearly stated "no go". Best regards, Seb "Sebastien Vauban" wrote: > Before Org 8 is out, I'm willing to put light on some last syntax which I find > counter-intuitive and not along the lines of the rest: it concerns the > `results' parameter. > > Let's sum up first the list of all parameters: > > 1. Collection > > - :results value > - :results output > > 2. Type of results (when :results is set to `value'): > > - Result types > > + :results vector > + :results scalar > + :results list > + :results file > > - Result wrappers > > + :results raw > + :results drawer > + :results org (removed, right?) > + :results html > + :results code > + :results latex > + :results pp > > 3. Handling > > - :results replace > - :results silent > - :results none > - :results append > - :results prepend > > As you see (by the shown structure), the different values answer different > questions: > > - How the results should be collected from the source code block? > - How they will be inserted into the Org mode buffer? > - How to interpret/wrap the results? > - How the results should be handled? > > And answering many of these questions at the same time means giving a > *multi-value* to the parameter, such as: > > :results list append > > Wouldn't it make more sense (and be more easily parsed by the machine and be > cleaner and less error-prone for us, poor humans) if `results' would be split > in different parameters for the different questions they answer, each of those > parameters getting at most one value? > > Something along the lines of: > > :results_type file :results_insertion append > > (those names may be ugly, it just for the purpose of explaining my idea). > > I know that it's the ultimate moment to discuss such a change, would there be > consensus, before Org 8 is out. -- Sebastien Vauban