From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [BUG] Inconsistency in src block hiding Date: Wed, 23 Nov 2011 16:25:48 +0100 Message-ID: <87y5v6x3lv.fsf@gmail.com> References: <8739djqfkv.fsf@gmail.com> <87fwhiwwr0.fsf@gmail.com> <87bos6pp1a.fsf@gmail.com> <8739dhnxjs.fsf@gmail.com> <87ipmcxboo.fsf@gmail.com> <87pqgjipu8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTEjR-0007ex-Cr for emacs-orgmode@gnu.org; Wed, 23 Nov 2011 10:27:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTEjO-0008M9-Qo for emacs-orgmode@gnu.org; Wed, 23 Nov 2011 10:27:29 -0500 Received: from mail-qw0-f48.google.com ([209.85.216.48]:57294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTEjO-0008M4-NR for emacs-orgmode@gnu.org; Wed, 23 Nov 2011 10:27:26 -0500 Received: by qady1 with SMTP id y1so339011qad.0 for ; Wed, 23 Nov 2011 07:27:25 -0800 (PST) In-Reply-To: <87pqgjipu8.fsf@gmail.com> (Eric Schulte's message of "Tue, 22 Nov 2011 16:23:18 -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 Eric Schulte writes: >> 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. I'm just thinking about a super-set of what's currently supported, that is to allow any order instead of a static one. So that's not really a problem. > 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. For now, you may be right. But I consider "#+header" as a continuation of the information specified at the block beginning line. With that in mind, there is at least one other block type that allows information there: example-block. So an "#+header" keyword could be as appropriate for it. I'm also thinking about Jambunathan's "#+begin_annotation". > 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. Not necessarily (see below). >> 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... Well, if we lived in a perfect world where anyone could smartly name things the first time they encounter them, I'll be on your side. But, the names I choose are often rather vague, so I'd always prefer to both see the name and a have a glimpse of the named object. Thus, when the wind is southerly, I can know a src-block from an example-block. That also explains why I dislike the "#+name:" hiding idea: lists, paragraphs, tables will all look the same. Also, it could potentially increase a lot the number of overlays used in a buffer, which isn't good performance-wise. >> 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. > I agree. I try nonetheless to make you see mine as more consistent than yours ;) >>>> 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. But borrowing parts of it is allowed in the game. More specifically, you need to copy and rename a single function `org-element-collect-affiliated-keywords', and four variables (`org-element--affiliated-re', `org-element-keyword-translation-alist', `org-element-parsed-keywords' and `org-element-dual-keywords'.) Now, in the following example, which will hurt your eyes, #+header: :var k=3 :exports code #+headers: :var k=2 #+caption: One more time. #+name: one-more-time #+begin_src emacs-lisp (1+ k) #+end_src calling (org-element-collect-affiliated-keywords) on the "#+begin_src" line will result in: (1 (:name "one-more-time" :caption ("One more time.") :header (":var k=3 :exports code" ":var k=2"))) 1 being the position at the beginning of the first "#+header:" line. So you get both the beginning position of the block (because "#+caption" and "#+name", being affiliated keywords, belong to the block in the same way as "#+header:" does) and all the info you need. And that, again, with only one function, not the full library (if you don't want to use the variables, you can pass their value as arguments to the function). >>>> 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... Is it possible to wrap all result types (e.g., > scalar, raw org text, tables, blocks) in drawers? Everything fits in a drawer, excepted another drawer, or an headline. It only needs to be defined in `org-drawers' or on the "#+drawers:" buffer property. When I want to center the output of a code block, I wrap it into a center-block. If I really want to hide it, I should be able to do the same with a drawer. But in both case, that's to the user discretion. So don't bother providing an option to automatically do this. >>> 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. So let's work towards drawers rehabilitation. Regards, -- Nicolas Goaziou