emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [BUG] Inconsistency in src block hiding


From: Eric Schulte
Subject: Re: [O] [BUG] Inconsistency in src block hiding
Date: Mon, 21 Nov 2011 11:24:39 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Eric Schulte <address@hidden> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]