From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Eric Schulte <eric.schulte@gmx.com>
Cc: Rick Frankel <rick@rickster.com>, emacs-orgmode@gnu.org
Subject: Re: [BUG] Inconsistency in src block hiding
Date: Tue, 24 Jan 2012 21:39:00 +0100 [thread overview]
Message-ID: <87k44gg7iz.fsf@gmail.com> (raw)
In-Reply-To: <87k44hn4uz.fsf@gmx.com> (Eric Schulte's message of "Mon, 23 Jan 2012 20:41:48 -0700")
Hello,
Eric Schulte <eric.schulte@gmx.com> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Changing the default drawer export behavior from "don't export" to "do
> export" would be surprising
Probably at first, but not for too long.
> would break many existing work flows
Not at all, since it's just a d:nil away from old behaviour.
Note that the current behavour is _not_ a d:t away from what I want to
implement. Indeed, even with d:t, you still need to change default
handler for drawers (org-export-format-drawer-function) as the default
one (org-export-format-drawer) will change drawer's contents into
a fixed-width area. For that task, an example block would have achieved
the same (hiding + verbatim).
> would likely make drawers less useful.
Certainly not, but I will that explain later.
> 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.
Then we may be running into problems, since my objective, with
org-element, is to provide a formal specification and normalization of
Org syntax. Along the way, some parts (hopefully few) in Org syntax will
need to be defined or re-defined.
Because only a very small number of persons can pretend to know every
part of Org syntax and even less (if any) to actually use them, we
definitely need guidelines to offer relevant future improvements.
Some current uses just don't fit in a global view: a recent example was
given by the caption syntax, which was heavily LaTeX oriented.
> 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.
Drawers should not add any semantics to the contents they are hiding.
They should be, as a default, neutral entities useful to hide stuff in
an Org buffer but certainly not to interfere with export.
1. There are already many ways to remove arbitrary contents from export.
Among them, one can find the :noexport: tag, comment blocks...
There's absolutely no need to add more.
2. They are better handled with regards to visibility cycling, which in
not the case of single keywords. Allowing to hide every single Org
syntax with a #+name: keyword could potentially be a mess.
3. By essence, drawers are better suited for hiding stuff than keywords,
since they allow to group any number of elements, whereas keywords
only apply to one keyword at a time.
4. Drawers are flexible. All major back-ends allow to configure
behaviour of drawers with regards to export. You can always decide to
keep :FOO: drawers transparent but remove any :BAR: drawer. It will
be even simpler with the new export engine.
On the other hand, I don't think that adding another special type for
drawers is the way to go. In general, adding new syntax should be done
with parsimony. In this case, it unnecessarilyrestricts possibilities:
why enforce a special behaviour for :RESULTS: since (point 4) you can
choose it?
I still vote for neutral drawers.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2012-01-24 20:41 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
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 [this message]
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=87k44gg7iz.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=eric.schulte@gmx.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).