Re: [O] [BUG] Inconsistency in src block hiding

[Nicolas Goaziou]

Hello,

Eric Schulte <address@hidden> writes:

> Nicolas Goaziou <address@hidden> 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