Rasmus writes:
> Pushed.
Thank you.
Regards,
Nicolas Goaziou writes:
> Rasmus writes:
>
>> So irrespective of this, here's an updated patch that uses
>> secondary-string parsing. Should I add it to master before or after I get
>> done with this moving description and keywords?
>
> You can go ahead, after fixing some minor typos. Thanks.
Rasmus writes:
> So irrespective of this, here's an updated patch that uses
> secondary-string parsing. Should I add it to master before or after I get
> done with this moving description and keywords?
You can go ahead, after fixing some minor typos. Thanks.
> * ox-latex.el (org-latex-format-s
Nicolas Goaziou writes:
> Since KEYWORDS and DESCRIPTION are really back-end dependant, I vote for
> moving them from `org-export-options-alist' to back-end definitions.
> Using `org-element-parse-secondary-string' will be required in this
> case.
> WDYT? Also, supposing you agree, do you want
Nicolas Goaziou writes:
> It isn't necessary to add :with-description and :with-keywords
> since :description and :keywords will not belong to "ox.el" anymore.
:With-keywords is still needed if they can be printed in both the text and
the meta data.
Keywords are also useful for weblogs, another
Rasmus writes:
> So are there any /other/ uses of DESCRIPTION but adding summaries to
> meta-data?
I can't think of any.
> Without much thought, these are the back-ends where it might make sense:
> ox-latex, ox-html, ox-texi, ox-odt, maybe ox-groff.
>
> In a second round, I might add a
Nicolas Goaziou writes:
> Since KEYWORDS and DESCRIPTION are really back-end dependant, I vote for
> moving them from `org-export-options-alist' to back-end definitions.
> Using `org-element-parse-secondary-string' will be required in this
> case.
OK.
So are there any /other/ uses of DESCRIPTIO
Rasmus writes:
> 'Cause usually org-export-data gives you the right value automatically.
> Anyway, I don't mind using org-element-parse-secondary-string.
`org-element-parse-secondary-string' is meant for cases like this one.
>> DESCRIPTION could be moved to `org-element-document-properties'. B
Nicolas Goaziou writes:
>> However, since they are plain strings something like \alpha will be
>> exported as $\backslash$lpha. I can kind of get it interpreting using
>> org-element-parse-secondary-string, but this is not the right
>> approach.
>
> Why isn't it the right approach?
'Cause usua
Hello,
Rasmus writes:
> Nicolas Goaziou writes:
>
>>> +(?k . ,(or (plist-get info :keywords) ""))
>>> +(?d . ,(or (plist-get info :description) ""))
>
> So it occurred to me that these should also be exported to proper syntax
> so we don't end up with e.g. a raw $ or & in our latex docu
Nicolas Goaziou writes:
>> +(?k . ,(or (plist-get info :keywords) ""))
>> +(?d . ,(or (plist-get info :description) ""))
So it occurred to me that these should also be exported to proper syntax
so we don't end up with e.g. a raw $ or & in our latex document. Hyperref
will actually handl
Hello,
Rasmus writes:
> This patch does two things.
>
> 1. Add better format-spec to ox-latex hyperref and title-command.
> 2. Use this to extend basic hyperref formatting to include title,
> author, language etc.
>
> Wrt the title-command, this is useful if you need one-off "c
Hi,
This patch does two things.
1. Add better format-spec to ox-latex hyperref and title-command.
2. Use this to extend basic hyperref formatting to include title,
author, language etc.
Wrt the title-command, this is useful if you need one-off "custom"
formatting of a header in
13 matches
Mail list logo
