Hello, Eric Schulte <schulte.e...@gmail.com> writes:
> Nicolas Goaziou <n.goaz...@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