From: Eric Schulte <schulte.eric@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Mon, 21 Nov 2011 11:24:39 -0700 [thread overview]
Message-ID: <8739dhnxjs.fsf@gmail.com> (raw)
In-Reply-To: <87bos6pp1a.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 20 Nov 2011 20:33:21 +0100")
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 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:".
Can you provide an example, I'm thinking that what you describe may not
be legal syntax. For example
#+name: one
#+results: two
- 1
- 2
doesn't make any more sense than
#+name: one
#+name: two
- 1
- 2
> 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.
>
Yes, I would agree, the hiding should be smart enough to find the whole
unit and hide it. I'll take a look at the code.
>
> 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.
>
The hiding was added because code blocks occasionally generate *huge*
results which make it impossible to read further down in the buffer.
Hiding such large results can be very useful when you want to keep the
data in-buffer, but still want to be able to read down the page.
Is there a way to bring the hiding of results more in-line with the
other methods of hiding in Org-mode? Should S-Tab be made to toggle the
hidden states of named entities as well as outline levels?
>
> 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.
>
I'll take a look at this and submit a patch.
Best -- Eric
>
>
> Regards,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2011-11-21 18:24 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 [this message]
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=8739dhnxjs.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--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).