From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [ANN] Org Export in contrib
Date: Sun, 27 Nov 2011 20:54:57 +0100 [thread overview]
Message-ID: <87obvxuyr2.fsf@gmail.com> (raw)
In-Reply-To: <C095E3CD-DA81-40E0-A3D7-45FF5D3638D2@gmail.com> (Carsten Dominik's message of "Sun, 27 Nov 2011 12:21:51 +0100")
Hello,
Carsten Dominik <carsten.dominik@gmail.com> writes:
>> 2. The document title cannot be obtained anymore from the first line of
>> text. It's either explicitely defined with the =TITLE= keyword, or
>> derived from buffer's name.
>
> This is actually good, I think. Much of the stuff like initial text,
> title from text etc are leftovers from early time. It might mean that
> we will have to keep the old exporters around somewhere, if someone
> needs compatibility.
We're not there yet. But I hope there will be no backward compatibility.
We really should remove from all export unrelated code the export
related text-properties.
>> 4. "[TABLE OF CONTENTS]" as a placeholder for the table of contents has
>> been removed. Though, a new keyword, =TOC=, achieves the same
>> effect, and can even take more values, like "contents", "tables",
>> "figures" and "listings". Tools are provided to make them available
>> to any exporter to come.
>
> What do you mean by "keyword"? Can you provide an example of how
> to place the TOC?
Just put "#+toc: headlines", "#+toc: tables", "#+toc: listings", "#+toc:
figures" anywhere in the document (at least with the LaTeX back-end).
>> 6. Macros have been under powered a little. They cannot live anymore in
>> comments, example blocks, or even src blocks. In fact, one cannot
>> find a macro where the text isn't parsed. Macros are Org syntax.
>> Using such syntax where there is, by definition, none is just
>> nonsensical.
>
> I know that Stefan Vollmar is using macros in complicated and
> extensive ways. I also know that he is using the index facilities,
> which so far have depended heavily on the preprocessor. I am curious
> how indexing will work with org-elements. Have you put any thought
> into this?
I don't think that macros will be a source of problems since comments
and example blocks were weird locations for them anyway.
In the LaTeX exporter, "#+index: something" will be transcoded into
"\index{something}". That's about it.
Should the generic export build a list of all "#+index:" values and
store it in a `:index' property (accessible through the communication
channel)?
>> 9. Table.el tables will always use their own export back-end. In other
>> words, no Org syntax will be recognized in such table anymore.
>> A table.el is an extraneous element while the parser is meant to
>> parse Org syntax.
> Maybe we should see if there is a hook in table.el which could
> be called to format text in a backend specific way. If it is not
> there, maybe we can simply introduce it ourselves, or add some
> advice for this purpose....
Ok. If anyone can look at it and determine the right thing to do, I will
merge it into the exporter code.
>> 11. =org-export-with-TeX-macros= has been replaced with the more
>> appropriate =org-export-with-entities=, and the associated =OPTIONS=
>> keyword's symbol changed from =TeX:nil= to =e:nil=.
>
> I do like the change, but maybe it would be good to support TeX
> for backward compatibility... Then, maybe, we are breaking a few
> things anyway.
TeX is still supported as a "latex-fragment". In the long run, though,
I think TeX commands that are not meant for dvipng/mathjax should be
called through an export snippet (that is "@l{...}" temporary syntax).
>> 12. About variables changes, =org-export-author-info=,
>> =org-export-creator-info= and =org-export-email-info= have been
>> replaced with, respectively, =org-export-with-author=,
>> =org-export-with-creator= ad =org-export-with-email=, for the sake
>> of consistency with other opt-in variables.
>
> Are you adding defvaralias for compatibility, or are you arguing for
> a clean break here?
There is no defvaralias. Though, I don't mind adding them.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2011-11-27 19:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-25 17:32 [ANN] Org Export in contrib Nicolas Goaziou
2011-11-25 18:57 ` Nicolas Goaziou
2011-11-27 11:21 ` Carsten Dominik
2011-11-27 19:54 ` Nicolas Goaziou [this message]
2011-11-28 11:40 ` Carsten Dominik
2011-11-28 19:38 ` Nicolas Goaziou
2011-11-27 11:06 ` Carsten Dominik
2011-11-29 6:15 ` Robert Klein
2011-11-29 6:34 ` Robert Klein
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=87obvxuyr2.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).