From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Sun, 20 Nov 2011 20:33:21 +0100 [thread overview]
Message-ID: <87bos6pp1a.fsf@gmail.com> (raw)
In-Reply-To: <87fwhiwwr0.fsf@gmail.com> (Eric Schulte's message of "Sun, 20 Nov 2011 08:53:53 -0700")
Eric Schulte <schulte.eric@gmail.com> writes:
> "name" is and should be an element of the `org-babel-data-names' list as
> it is the preferred way to name data in an Org-mode file, e.g.,
>
> #+name: foo
> - 1
> - 2
> - 3
I agree.
> The only reason that "tblname" and "results" are included in the list
> are because "tblname" is used by other parts of Org-mode, and "results"
> was retained because it was felt that a "name" line without an actual
> name (e.g., as the results of an un-named code block) would look funny.
>
> I don't view the "results style" hiding as inconsistent
It is inconsistent when keywords stack on top of each other. If you have
only a "#+name:" keyword, block with fold at the "#+name:" level. If you
have both "#+name:" and, for example "#+results" below, block will fold
at the "#+result:" level and TAB will not respond at "#+name:". If you
have, from top to bottom, "name", "results" "header", nothing will fold.
In all those cases, I think a consistent behaviour could be to hide the
block, with any number of keywords above, and TAB pressed at any of
them.
I'm not sure that "#+results:" or "#+name:" keywords should allow to
hide whole parts of the buffer. I realize that toggling "#+results:"
visibility has been in core for a while. But now that every Org blob can
have a "#+name" attached to it, one can hide almost anything in the
buffer.
Until now we could hide contents with headlines, blocks, drawers, and
items (with an option to prevent it). And we had a global mechanism to
handle visibility toggling just fine (namely S-TAB with different
numbers of prefixes). But hiding independently each list, table or
paragraph with no possibility to make them appear in groups just doesn't
sound right.
Hence, I suggest to think again about it: we can live happily with
outlines, blocks and drawers as folding entities.
Moreover, there is another problem related to that.
`org-export-blocks-preprocess' will remove all "#+name:" keywords in the
buffer. It mustn't: again "#+name:" is a general naming mechanism for
almost any Org syntax. It may/will be also used for other purpose than
Babel. That information is important even after blocks have been
processed.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2011-11-20 19:35 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 [this message]
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
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=87bos6pp1a.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@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).