From: Nick Dokos <nicholas.dokos@hp.com>
To: =?utf-8?Q?Fran=C3=A7ois?= Pinard <pinard@iro.umontreal.ca>
Cc: emacs-orgmode@gnu.org
Subject: Re: Multiple (natural) languages in a single org-file
Date: Wed, 11 Apr 2012 01:23:34 -0400 [thread overview]
Message-ID: <3699.1334121814@alphaville> (raw)
In-Reply-To: Message from pinard@iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) of "Tue\, 10 Apr 2012 21\:19\:51 EDT." <86lim35ako.fsf@iro.umontreal.ca>
François Pinard <pinard@iro.umontreal.ca> wrote:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
> > Just use two different drawer names, and select which one to actually
> > export through i.e. #+OPTIONS: d:("EN"). No need for extra syntax.
>
> Well, the manual says, in node Export options:
>
> d: turn on/off inclusion of drawers
>
> So one would never guess from the manual that d: may accept drawer
> names. If what Nicolas suggests is real, the documentation should be
> adjusted. I do not find any other explanation in the manual about
> values for the d: option.
>
Two paragraphs below the d: line you found, the manual says
,----
| The default values for these and many other options are given by a
| set of variables. For a list of such variables, the corresponding
| OPTIONS keys and also the publishing keys (*note Project alist::), see
| the constant `org-export-plist-vars'.
`----
Examining the value of org-export-plist-vars shows
,----
| ...
| (:drawers "d" org-export-with-drawers)
| ...
`----
Also, in section 13.1.5, (info "(org) Options for the HTML/LaTeX
exporters"), it says
,----
| The table below lists these properties along with
| the variable they belong to. See the documentation string for the
| respective variable for details.
|
| ...
| `:drawers' `org-export-with-drawers'
| ...
`----
and examining the doc of org-export-with-drawers (with C-h v) we find:
,----
| Non-nil means export with drawers like the property drawer.
| When t, all drawers are exported. This may also be a list of
| drawer names to export.
`----
None of this is an argument for leaving the manual as is: if you had a
problem finding the information, then others will too, so the manual
should be improved.
But the information is there, and moreover, learning how to find it in
this instance has the huge advantage of teaching one how to find it for
all the other options as well. The question as always is how far to go
in documenting all the options: it would be good to document them all
(as Bastien would say: "patches are welcome"), but is it better to learn
searching tricks or to submit patches to improve the doc? Each one of us
would probably answer that question differently (we have different
"breaking points"). So you might prepare a doc patch (please do!) - I
might go on a searching expedition and find things you didn't [fn:1].
The first one benefits everybody, the second one benefits mainly me, but
sometimes I can find a teaching moment and tell other people how to do
something: which is why I spent a half-hour writing this :-) [fn:2]
I think both of these methods (and surely there are other methods as
well) have some value - and some drawbacks as well, but I'll leave that
for another time.
Nick
Footnotes:
[fn:1] If I think it's easier, I'll search in the sources, rather than
the manual, but that's just me :-) I'm not advocating this as a general
solution of course - otoh, once you have a basic grasp of lisp, it's a
great way to learn how to read programs - real-life, non-trivial
programs at that.
[fn:2] For me, the puzzle aspects are more interesting: I'm not a
"power-user" of org, and I use maybe 1/10 of its capabilities. But when
I'm climbing walls and I need a distraction, a good juicy question on
org-mode is just what the doctor ordered...
next prev parent reply other threads:[~2012-04-11 5:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 10:45 Multiple (natural) languages in a single org-file Carlos Russo
2012-03-01 11:05 ` Carlos Russo
2012-03-01 12:37 ` Nicolas Goaziou
2012-04-11 1:19 ` François Pinard
2012-04-11 5:23 ` Nick Dokos [this message]
2012-04-11 6:30 ` Bastien
2012-04-11 6:18 ` Bastien
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=3699.1334121814@alphaville \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=pinard@iro.umontreal.ca \
/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).