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: Tue, 22 Nov 2011 19:19:03 +0100 [thread overview]
Message-ID: <87ipmcxboo.fsf@gmail.com> (raw)
In-Reply-To: <8739dhnxjs.fsf@gmail.com> (Eric Schulte's message of "Mon, 21 Nov 2011 11:24:39 -0700")
Hello,
Eric Schulte <schulte.eric@gmail.com> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> 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.
Consider the following cases:
--8<---------------cut here---------------start------------->8---
#+name: one-more
#+header: :var k=2
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+header: :var k=2
#+name: one-more
#+begin_src emacs-lisp
(1+ k)
#+end_src
#+attr_html: :textarea t :height 10 :width 40
#+name: unique-name
#+begin_example
Edit me!
#+end_example
--8<---------------cut here---------------end--------------->8---
Note that the second case doesn't appear to be legal, as executing the
block errors out with "Symbol's value as variable is void: k". I don't
think that there should be any imposed order in affiliated keywords.
Anyway, in the first case, block will be hidden only when TAB is pressed
on the "#+begin_src" line. In the second case, block can be hidden when
TAB is pressed on both the "#+name:" and the "#+begin_" line, with two
different results. That's confusing.
Only lines below "#+begin_" should be hidden, with TAB pressed on any
keyword. Affiliated keywords should always be visible.
>> 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.
Or rely on Org Elements... *coughs*
>> 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.
Then wraps a drawer around the result. Their purpose is to hide
arbitrary large parts of a buffer. Why inventing yet another way?
> 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?
Again, drawers are in-line with standard hiding methods. Though, their
behaviour with regards to export needs to be changed (i.e. by default
simply export contents of the drawer instead of ignoring it).
I think we should drop any "#+result:" or "#+name:" hiding and take
another route. It's not their job anyway.
>> `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.
You took care of the problem even before I could thank you for thinking
about fixing it.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2011-11-22 18:20 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 [this message]
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=87ipmcxboo.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).