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: Tue, 22 Nov 2011 16:23:18 -0700	[thread overview]
Message-ID: <87pqgjipu8.fsf@gmail.com> (raw)
In-Reply-To: 87ipmcxboo.fsf@gmail.com

>
> Consider the following cases:
>
> #+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
>
> 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.
>

I would say that the first and third should be valid constructions, but
the second should not.  This is for two reasons.

1. As you point out the second is not currently supported, and generally
   changing the code should be avoided.

2. More importantly, unlike the #+attr_html line in the third example,
   the #+header line *only* applies to code blocks and not to any other
   Org-mode element.  Given that I think it is part of the code block in
   a more intimate way than #+name is part of the code block, and thus
   should not be separated from the code block by a name.  In effect I
   think of the code block (including the #+header line) as an Org-mode
   object, and the #+name line as something applied to that element as a
   whole.

I suppose I would yield to you on this point as you actually have a
systematic way of defining Org-mode objects and keywords (org-elements),
where as all I have is intuition and the vague notion that option two
above "looks ugly" to me.

Although, that said I don't really look forward to the task of changing
the code to allow any arbitrary sequence of #+name and #+header
arguments prefixing a code block as it will complicate the current code
significantly.

>
> Anyway, in the first case, block will be hidden only when TAB is pressed
> on the "#+begin_src" line.

In the current code it will also be hidden if TAB is pressed on the
#+name 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.
>

I did work out a version of this patch in which when tab was pressed on
the #+name line, only the code block was hidden, however in my
conception where names can be applied to any Org-mode object, and
intervening #+header lines are part of the code block it seemed more
consistent to hide the whole object following the name, so e.g., hiding
this with TAB on #+name

#+name: one-more
#+header: :var k=2
#+begin_src emacs-lisp
(1+ k)
#+end_src

should result in this (as it does now)

#+name: one-more...

rather than this

#+name: one-more
#+header: :var k=2
#+begin_src emacs-lisp...

>
> Only lines below "#+begin_" should be hidden, with TAB pressed on any
> keyword. Affiliated keywords should always be visible.
>

I see your view, and it is consistent, it is just different from mine.

>
>
>>> 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 agree, Ideally I would love to only manipulate the list provided by
org-element.el, however now I am more concerned with changes before the
upcoming Emacs merge before the release of Emacs24.  So relying on
org-elements is not currently an option.

>
>>> 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?
>

I like this idea, and would be happy to strip all hiding functionality
away from results... It it possible to wrap all result types (e.g.,
scalar, raw org text, tables, blocks) in drawers?

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

Fair enough, I like this idea.

Cheers,

>
>>> `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,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

  reply	other threads:[~2011-11-23  1:34 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 [this message]
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=87pqgjipu8.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).