From: tsd@tsdye.com (Thomas S. Dye)
To: Jonathan Leech-Pepin <jonathan.leechpepin@gmail.com>
Cc: Nicolas Goaziou <n.goaziou@gmail.com>, Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [org-e-texinfo] generate menu items
Date: Fri, 23 Nov 2012 13:44:05 -1000 [thread overview]
Message-ID: <m1y5hrnauy.fsf@tsdye.com> (raw)
In-Reply-To: <CAEWDx5dtN0PGgUKF1qBSUow4PVXuisu4mdTdcD7RuL+g0Rb5NQ@mail.gmail.com> (Jonathan Leech-Pepin's message of "Wed, 21 Nov 2012 11:31:33 -0500")
Aloha Jon,
Thanks very much for these changes, which appear to work nicely with the
draft Org manual.
What do you think about the various macro commands defined in org.texi?
How to put them in the Org file and then get them into the texinfo
output? The org.texi file has them between @finalout and @copying. I
don't know if they have to be there, but I assume they were put there
for a reason.
All the best,
Tom
Jonathan Leech-Pepin <jonathan.leechpepin@gmail.com> writes:
> Hello Tom, Nicolas,
>
> I've just pushed a change that should provide the desired results.
>
> The optional title for the menu entries (as well as associated node
> headings) can be set using the :TEXINFO_MENU_TITLE: property.
>
> On 18 November 2012 11:22, Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>> > tsd@tsdye.com (Thomas S. Dye) writes:
>> >
>> >> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> >
>> >>> That's a bit of work, because, so far, node-property values are not
>> >>> parsed. So it would require to define a new class of node-properties:
>> >>> those with a parsed value. But then, how to decide which properties
>> have
>> >>> their value parsed are parsed and which have not?
>> >
>> >> Thanks for the information and explanation. Back-end-specific
>> >> properties should work nicely in this case.
>> >>
>> >> I'll wait to see what Jonathan thinks about the original query.
>> >
>> > Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this
>> > one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, I can
>> > give it a try.
>> >
>>
>
> If you do include these node properties I can then adjust the texinfo
> exporter to use the generic TOC/Optional title property rather than a
> backend specific one.
>
>
> Regards,
>
> --
> Jon
>
>
>> > I would be consistent with #+caption[short]: long for other elements.
>> >
>> >
>> > Regards,
>>
>> I'm biased by LaTeX, which uses the optional argument for the TOC and
>> running heads. Since the back-ends are free to use this optional entry
>> as they please, and not only for the TOC, perhaps :EXPORT_SHORT_ENTRY:
>> (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY:
>> (because the back-end has the option to use it where appropriate).
>>
>> All the best,
>> Tom
>>
>> --
>> Thomas S. Dye
>> http://www.tsdye.com
>>
>>
> Hello Tom, Nicolas,
>
> I've just pushed a change that should provide the desired results.
>
> The optional title for the menu entries (as well as associated node
> headings) can be set using the :TEXINFO_MENU_TITLE: property.
>
> On 18 November 2012 11:22, Thomas S. Dye <tsd@tsdye.com> wrote:
>
>
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
> > tsd@tsdye.com (Thomas S. Dye) writes:
> >
> >> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> >
> >>> That's a bit of work, because, so far, node-property values
> are not
> >>> parsed. So it would require to define a new class of
> node-properties:
> >>> those with a parsed value. But then, how to decide which
> properties have
> >>> their value parsed are parsed and which have not?
> >
> >> Thanks for the information and explanation. Back-end-specific
> >> properties should work nicely in this case.
> >>
> >> I'll wait to see what Jonathan thinks about the original query.
> >
> > Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this
> > one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed,
> I can
> > give it a try.
> >
>
>
> If you do include these node properties I can then adjust the texinfo
> exporter to use the generic TOC/Optional title property rather than a
> backend specific one.
>
>
> Regards,
>
> --
> Jon
>
>
>
> > I would be consistent with #+caption[short]: long for other
> elements.
> >
> >
> > Regards,
>
>
> I'm biased by LaTeX, which uses the optional argument for the TOC
> and
> running heads. Since the back-ends are free to use this optional
> entry
> as they please, and not only for the TOC, perhaps
> :EXPORT_SHORT_ENTRY:
> (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY:
> (because the back-end has the option to use it where appropriate).
>
>
> All the best,
> Tom
>
> --
>
>
> Thomas S. Dye
> http://www.tsdye.com
>
>
>
--
Thomas S. Dye
http://www.tsdye.com
next prev parent reply other threads:[~2012-11-23 23:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 18:10 [org-e-texinfo] generate menu items Thomas S. Dye
2012-11-17 18:50 ` Nicolas Goaziou
2012-11-17 19:56 ` Thomas S. Dye
2012-11-17 21:11 ` Nicolas Goaziou
2012-11-17 21:48 ` Thomas S. Dye
2012-11-17 22:33 ` Nicolas Goaziou
2012-11-17 23:24 ` Thomas S. Dye
2012-11-18 9:02 ` Nicolas Goaziou
2012-11-18 16:22 ` Thomas S. Dye
2012-11-21 16:31 ` Jonathan Leech-Pepin
2012-11-23 23:44 ` Thomas S. Dye [this message]
2013-02-23 23:04 ` Nicolas Goaziou
2013-02-25 16:00 ` Jonathan Leech-Pepin
2013-02-25 16:09 ` Nicolas Goaziou
2013-02-25 16:12 ` Jonathan Leech-Pepin
2013-02-25 17:02 ` Thomas S. Dye
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=m1y5hrnauy.fsf@tsdye.com \
--to=tsd@tsdye.com \
--cc=emacs-orgmode@gnu.org \
--cc=jonathan.leechpepin@gmail.com \
--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).