emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [BUG] Inconsistency in src block hiding


From: Eric Schulte
Subject: Re: [O] [BUG] Inconsistency in src block hiding
Date: Sun, 11 Dec 2011 09:25:39 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Bastien <address@hidden> writes:
>
>> Eric Schulte <address@hidden> writes:
>>
>>> The attached patch entirely removes the #+name and #+results based
>>> hiding.  Note that the existing "wrap" argument to the ":results" header
>>> argument will wrap results in a block which allows easy tab-based result
>>> hiding.
>
> I didn't notice it before, but the wrap option from :results property
> could also be removed. Unlike to every other block "#+begin_results"
> doesn't add any meaning. Its sole purpose is to group some Org data,
> which is the job of drawers.
>
> Moreover, it's already easy to install results in a block (I use it to
> center results). You only need to put the results line in an appropriate
> location and evaluate the code block, like in the following:
>
> #+name: four
> #+begin_src emacs-lisp
> (+ 2 2)
> #+end_src
>
> #+begin_center
> #+results: four
> #+end_center
>

One major utility of the wrap :results header argument is that it allows
blocks of raw Org-mode text returned by a code block to be automatically
replaced on every execution.  This is possible because the wrapping
block is used to delimit the result in the Org-mode file.  This is not
possible with your solution above.

>
> Note that the wrap argument may be used instead to wrap results in
> a :RESULTS: drawer, but that default drawer would have then to be added
> to the `org-drawers' list, and, in the end, wouldn't be very practical.
>

I agree a :RESULTS: drawer would be a more meaningful way to wrap code
block results.  I don't see why such a solution is not practical.  I
just pushed up a change that defaults to wrapping results in new RESULTS
drawers rather than blocks.

>
> In my opinion, we should forget any will to automatically group results
> (because there is no option more interesting than others) and let the
> user decide what suits him the best.
>

I would disagree because of the result delimitation functionality
mentioned above.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]