emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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/

  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).