From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [ANN] Org Export in contrib
Date: Mon, 28 Nov 2011 12:40:20 +0100 [thread overview]
Message-ID: <E3014080-60D1-429C-84B8-2D689AA96666@gmail.com> (raw)
In-Reply-To: <87obvxuyr2.fsf@gmail.com>
On Nov 27, 2011, at 8:54 PM, Nicolas Goaziou wrote:
> 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.
Yes, I agree.
>
>>> 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).
OK, thanks.
>
>>> 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)?
Yes, I think so!
>
>>> 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.
I will try to look at this possibility.
Cheers
- Carsten
>
>>> 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
- Carsten
next prev parent reply other threads:[~2011-11-28 11:40 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
2011-11-28 11:40 ` Carsten Dominik [this message]
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=E3014080-60D1-429C-84B8-2D689AA96666@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@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).