From: Eric Schulte <eric.schulte@gmx.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Rick Frankel <rick@rickster.com>, emacs-orgmode@gnu.org
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Mon, 23 Jan 2012 20:41:48 -0700 [thread overview]
Message-ID: <87k44hn4uz.fsf@gmx.com> (raw)
In-Reply-To: 87ty3r4hop.fsf@gmail.com
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> Eric Schulte <eric.schulte@gmx.com> writes:
>
>> Thanks for taking the time to collect these changes into a patch,
>> however I believe the changes you describe present /new/ behavior (e.g.,
>> new export semantics for drawers), rather than a bug repair.
>
> I'd rather say that its intent is to fix an old bug: incomplete
> specifications of drawers. Also, I don't add export semantics for
> drawers: I remove any, by default.
>
I apologize if I come across as argumentative, but I disagree with the
statement above. The tag-line to the "Drawers" section in the manual is
"Tucking stuff away" which I think is often how drawers are used.
Changing the default drawer export behavior from "don't export" to "do
export" would be surprising, would break many existing work flows, and
would likely make drawers less useful.
In general I think the Org-mode specification is best defined by how
Org-mode is used and how it may be more easily and intuitively used in
the future. Org-mode doesn't currently have a formal specification, and
I think that is a good thing. Formal specification don't prevent bugs,
they just move them from the code to the spec.
Incidentally this is also why I consider the loss of result folding to
be a regression because it breaks existing usage patterns.
>
> Again, drawers allow to fold any part of an Org buffer without adding
> semantics to its contents. It's a more general solution than
> keywords. But you already know that.
>
>> For the time being I am going to bring back results folding until an
>> acceptable alternative can be agreed upon and implemented.
>
> There is already an acceptable alternative. I sincerely hope that
> reverting this won't make it impossible to be implemented later.
>
There is no rule against reverting a revision :), so we could always do
that if there is a consensus on list.
To my mind a better path moving forward would be to change the behavior
of the :RESULTS: drawer so that it is exported but *not* to change the
default drawer export behavior. This way with a :wrap header argument
the code block results could be hidden with tab but would still be
exported.
PRO: allows hiding code block results with tab, makes it clear where
results begin and end, uses drawers for hiding which is what
they are designed for, avoids the potential for hiding anything
with a name
CON: more syntactic weight around results, changes the existing
default behavior, makes the "RESULTS" drawer a special type of
drawer
There is likely a better option but this is the best that comes to mind.
Personally I am also content with the current behavior in which anything
under a #+name: may be hidden.
Cheers,
>
>
> Regards,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2012-01-24 3:42 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
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 [this message]
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=87k44hn4uz.fsf@gmx.com \
--to=eric.schulte@gmx.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
--cc=rick@rickster.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).