From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [BUG] Inconsistency in src block hiding Date: Mon, 21 Nov 2011 11:24:39 -0700 Message-ID: <8739dhnxjs.fsf@gmail.com> References: <8739djqfkv.fsf@gmail.com> <87fwhiwwr0.fsf@gmail.com> <87bos6pp1a.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSYXx-00007S-PW for emacs-orgmode@gnu.org; Mon, 21 Nov 2011 13:24:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSYXt-00053r-R9 for emacs-orgmode@gnu.org; Mon, 21 Nov 2011 13:24:49 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:34847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSYXt-00053U-IJ for emacs-orgmode@gnu.org; Mon, 21 Nov 2011 13:24:45 -0500 Received: by iaek3 with SMTP id k3so11074914iae.0 for ; Mon, 21 Nov 2011 10:24:44 -0800 (PST) In-Reply-To: <87bos6pp1a.fsf@gmail.com> (Nicolas Goaziou's message of "Sun, 20 Nov 2011 20:33:21 +0100") 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 Nicolas Goaziou writes: > Eric Schulte writes: > >> "name" is and should be an element of the `org-babel-data-names' list as >> it is the preferred way to name data in an Org-mode file, e.g., >> >> #+name: foo >> - 1 >> - 2 >> - 3 > > I agree. > >> The only reason that "tblname" and "results" are included in the list >> are because "tblname" is used by other parts of Org-mode, and "results" >> was retained because it was felt that a "name" line without an actual >> name (e.g., as the results of an un-named code block) would look funny. >> >> I don't view the "results style" hiding as inconsistent > > 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. For example #+name: one #+results: two - 1 - 2 doesn't make any more sense than #+name: one #+name: two - 1 - 2 > 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. > > 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. 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? > > Moreover, there is another problem related to that. > > `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. Best -- Eric > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/