From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Wed, 23 Nov 2011 16:25:48 +0100 [thread overview]
Message-ID: <87y5v6x3lv.fsf@gmail.com> (raw)
In-Reply-To: <87pqgjipu8.fsf@gmail.com> (Eric Schulte's message of "Tue, 22 Nov 2011 16:23:18 -0700")
Eric Schulte <schulte.eric@gmail.com> 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
next prev parent reply other threads:[~2011-11-23 15:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-20 10:00 [BUG] Inconsistency in src block hiding Nicolas Goaziou
2011-11-20 15:53 ` Eric Schulte
2011-11-20 19:33 ` Nicolas Goaziou
2011-11-21 18:24 ` Eric Schulte
2011-11-22 16:15 ` Eric Schulte
2011-11-22 18:19 ` Nicolas Goaziou
2011-11-22 23:23 ` Eric Schulte
2011-11-23 15:25 ` Nicolas Goaziou [this message]
2011-11-28 8:09 ` Eric Schulte
2011-12-11 13:53 ` Bastien
2011-12-11 14:08 ` Nicolas Goaziou
2011-12-11 16:25 ` Eric Schulte
2011-12-11 16:04 ` Eric Schulte
2011-12-11 17:04 ` Bastien
2012-01-17 2:26 ` Bernt Hansen
2012-01-17 17:49 ` Nicolas Goaziou
2012-01-17 17:59 ` Bernt Hansen
2012-01-18 10:45 ` Leo Alekseyev
2012-01-18 16:02 ` Rick Frankel
2012-01-18 16:19 ` Eric Schulte
2012-01-18 17:36 ` Nicolas Goaziou
2012-01-19 12:10 ` Martyn Jago
2012-01-19 14:48 ` Eric Schulte
2012-01-19 15:22 ` Rick Frankel
2012-01-19 19:18 ` Nicolas Goaziou
2012-01-19 14:41 ` Eric Schulte
2012-01-19 19:26 ` Nicolas Goaziou
2012-01-24 3:41 ` Eric Schulte
2012-01-24 4:23 ` Leo Alekseyev
2012-01-24 4:44 ` Jambunathan K
2012-01-24 7:59 ` Andreas Leha
2012-01-24 20:39 ` Nicolas Goaziou
2012-01-28 16:08 ` Nicolas Goaziou
2012-01-25 0:00 ` Nick Dokos
2012-01-25 2:23 ` Bernt Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5v6x3lv.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).