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: Tue, 22 Nov 2011 16:23:18 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

>
> 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/



reply via email to

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