From: Eric Schulte <eric.schulte@gmx.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Bastien <bzg@altern.org>, Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Sun, 11 Dec 2011 09:25:39 -0700 [thread overview]
Message-ID: <87y5uj6obx.fsf@gmx.com> (raw)
In-Reply-To: 87k4632ob1.fsf@gmail.com
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Bastien <bzg@altern.org> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> 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/
next prev parent reply other threads:[~2011-12-11 16:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-20 10:00 [BUG] Inconsistency in src block hiding Nicolas Goaziou
2011-11-20 15:53 ` Eric Schulte
2011-11-20 19:33 ` Nicolas Goaziou
2011-11-21 18:24 ` Eric Schulte
2011-11-22 16:15 ` Eric Schulte
2011-11-22 18:19 ` Nicolas Goaziou
2011-11-22 23:23 ` Eric Schulte
2011-11-23 15:25 ` Nicolas Goaziou
2011-11-28 8:09 ` Eric Schulte
2011-12-11 13:53 ` Bastien
2011-12-11 14:08 ` Nicolas Goaziou
2011-12-11 16:25 ` Eric Schulte [this message]
2011-12-11 16:04 ` Eric Schulte
2011-12-11 17:04 ` Bastien
2012-01-17 2:26 ` Bernt Hansen
2012-01-17 17:49 ` Nicolas Goaziou
2012-01-17 17:59 ` Bernt Hansen
2012-01-18 10:45 ` Leo Alekseyev
2012-01-18 16:02 ` Rick Frankel
2012-01-18 16:19 ` Eric Schulte
2012-01-18 17:36 ` Nicolas Goaziou
2012-01-19 12:10 ` Martyn Jago
2012-01-19 14:48 ` Eric Schulte
2012-01-19 15:22 ` Rick Frankel
2012-01-19 19:18 ` Nicolas Goaziou
2012-01-19 14:41 ` Eric Schulte
2012-01-19 19:26 ` Nicolas Goaziou
2012-01-24 3:41 ` Eric Schulte
2012-01-24 4:23 ` Leo Alekseyev
2012-01-24 4:44 ` Jambunathan K
2012-01-24 7:59 ` Andreas Leha
2012-01-24 20:39 ` Nicolas Goaziou
2012-01-28 16:08 ` Nicolas Goaziou
2012-01-25 0:00 ` Nick Dokos
2012-01-25 2:23 ` Bernt Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5uj6obx.fsf@gmx.com \
--to=eric.schulte@gmx.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).