From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [BUG] Inconsistency in src block hiding Date: Tue, 22 Nov 2011 16:23:18 -0700 Message-ID: <87pqgjipu8.fsf@gmail.com> References: <8739djqfkv.fsf@gmail.com> <87fwhiwwr0.fsf@gmail.com> <87bos6pp1a.fsf@gmail.com> <8739dhnxjs.fsf@gmail.com> <87ipmcxboo.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:39102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RT1ji-0000L9-CS for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 20:34:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RT1jg-0000ZV-3Q for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 20:34:54 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:43717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RT1jf-0000Ym-Ro for emacs-orgmode@gnu.org; Tue, 22 Nov 2011 20:34:51 -0500 Received: by iaek3 with SMTP id k3so1318080iae.0 for ; Tue, 22 Nov 2011 17:34:50 -0800 (PST) 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: Nicolas Goaziou Cc: Org Mode List > > 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/