From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [BUG] Inconsistency in src block hiding Date: Tue, 22 Nov 2011 19:19:03 +0100 Message-ID: <87ipmcxboo.fsf@gmail.com> References: <8739djqfkv.fsf@gmail.com> <87fwhiwwr0.fsf@gmail.com> <87bos6pp1a.fsf@gmail.com> <8739dhnxjs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:33447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSuxY-00041M-Vj for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 13:20:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSuxX-0003SC-L1 for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 13:20:44 -0500 Received: from mail-bw0-f41.google.com ([209.85.214.41]:32958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSuxX-0003S0-Bc for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 13:20:43 -0500 Received: by bke17 with SMTP id 17so670063bke.0 for ; Tue, 22 Nov 2011 10:20:42 -0800 (PST) In-Reply-To: <8739dhnxjs.fsf@gmail.com> (Eric Schulte's message of "Mon, 21 Nov 2011 11:24:39 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Org Mode List Hello, Eric Schulte writes: > Nicolas Goaziou 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