[PATCH] Re: Inconsistent use of \ref and \eqref in ox-latex and ox-html
Nicolas, thank you for the feedback, and I apologize for my errors.
On Sun, Apr 19 2020, Nicolas Goaziou wrote:
>
> You need to provide a commit message, using git format-patch
> mechanism.
>
Apologies while I learn the procedure. I have corrected the issues below and
generated a commit patch attached. Please let me know if there are any problems.
> However, it would be nice to reference that variable in
>
> Publishing > Configuration > Options for the exporters > HTML specific
> properties
>
It is now listed in this section and removed from the others.
>
> It might be useful to explicitly state this is a format control string,
> expecting a single argument, the actual reference.
>
>
> It should be "9.4".
>
Both are corrected.
>
> Indentation problem?
>
The indentation problem is in the original org code.
Thank you for all of your help and efforts.
Cheers,
Brian
>From a7c078e4b5f3d97fa7db0e1df192e26e6953ef71 Mon Sep 17 00:00:00 2001
From: Brian Powell
Date: Sun, 19 Apr 2020 12:59:53 -1000
Subject: [PATCH] add org-html-equation-reference-format to customize MathJax
ref command
---
doc/org-manual.org | 1 +
lisp/ox-html.el| 23 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6d5a34e56..4b1a14ef4 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -15851,6 +15851,7 @@ Settings]]), however, override everything.
| ~:html-link-use-abs-url~ | ~org-html-link-use-abs-url~ |
| ~:html-mathjax-options~| ~org-html-mathjax-options~|
| ~:html-mathjax-template~ | ~org-html-mathjax-template~ |
+| ~:html-equation-reference-format~ | ~org-html-equation-reference-format~ |
| ~:html-metadata-timestamp-format~ | ~org-html-metadata-timestamp-format~ |
| ~:html-postamble-format~ | ~org-html-postamble-format~ |
| ~:html-postamble~ | ~org-html-postamble~ |
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index e70b8279b..0565d47f0 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -121,6 +121,7 @@
(:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
(:html-link-up "HTML_LINK_UP" nil org-html-link-up)
(:html-mathjax "HTML_MATHJAX" nil "" space)
+(:html-equation-reference-format "HTML_EQUATION_REFERENCE_FORMAT" nil org-html-equation-reference-format t)
(:html-postamble nil "html-postamble" org-html-postamble)
(:html-preamble nil "html-preamble" org-html-preamble)
(:html-head "HTML_HEAD" nil org-html-head newline)
@@ -761,6 +762,22 @@ The function should return the string to be exported."
LaTeX
+(defcustom org-html-equation-reference-format "\\eqref{%s}"
+ "MathJax command to use when referencing equations. This is a
+format controls string, expecting a single argument, the equation
+being referenced that is generated on export.
+
+Default is to wrap equations in parentheses (using \"\\eqref{%s}\)\".
+
+Most common values are:
+
+ \"\\eqref{%s}\"Wrap the equation in parentheses
+ \"\\ref{%s}\" Do not wrap the equation in parentheses"
+ :group 'org-export-html
+ :package-version '(Org . "9.4")
+ :type 'string
+ :safe t)
+
(defcustom org-html-with-latex org-export-with-latex
"Non-nil means process LaTeX math snippets.
@@ -3113,9 +3130,9 @@ INFO is a plist holding contextual information. See
(eq 'latex-environment (org-element-type destination))
(eq 'math (org-latex--environment-type destination)))
;; Caption and labels are introduced within LaTeX
- ;; environment. Use "eqref" macro to refer to those in
- ;; the document.
- (format "\\eqref{%s}"
+ ;; environment. Use "ref" or "eqref" macro, depending on user
+ ;; preference to refer to those in the document.
+ (format (plist-get info :html-equation-reference-format)
(org-export-get-reference destination info))
(let* ((ref (org-export-get-reference destination info))
(org-html-standalone-image-predicate
--
2.26.0
Re: babel/noweb concatenation of equally-named code blocks fails?
Nicolas, thanks for the history! sounds like a good tradeoff. i agree, a bit more documentation would be good. cheers, Greg
Re: babel/noweb concatenation of equally-named code blocks fails?
Greg Minshall writes: > Nicolas, thanks. i take it this is a change from (recent?) past > behavior? I think this was done between Org 9.1 and 9.2, the final step probably being 99dbca3d4f2fb30f35309a0bf4c324535b7dc9f3 > it was kind of nice the old way, but i suspect i'll get used > to the new way (no names, just noweb-ref) fairly soon. Mixing noweb-ref and names slowed down Noweb expansion very much. We papered over it using that odd variable: `org-babel-use-quick-and-dirty-noweb-expansion'. IOW, you had to choose between speed and accuracy when expanding Noweb blocks. Now, this is simpler: using NAME keyword is the fast path, with a single block. Using :noweb-ref is the slow path, but you can concatenate multiple blocks.
Re: babel/noweb concatenation of equally-named code blocks fails?
Nicolas, thanks. i take it this is a change from (recent?) past behavior? it was kind of nice the old way, but i suspect i'll get used to the new way (no names, just noweb-ref) fairly soon. cheers, Greg
Re: babel/noweb concatenation of equally-named code blocks fails?
Hello, Greg Minshall writes: > hi. the description of :noweb-ref says > > When expanding “noweb” style references, the bodies of all code block > with _either_ a block name matching the reference name _or_ a > ‘:noweb-ref’ header argument matching the reference name will be > concatenated together to form the replacement text. Yes this part of the manual is not particularly clear, I'll try to reformulate it. Anyway, names are assumed to be unique throughout a document. If you want to concatenate multiple blocks, you need to use :noweb-ref. HTH, -- Nicolas Goaziou
babel/noweb concatenation of equally-named code blocks fails?
hi. the description of :noweb-ref says
When expanding “noweb” style references, the bodies of all code block
with _either_ a block name matching the reference name _or_ a
‘:noweb-ref’ header argument matching the reference name will be
concatenated together to form the replacement text.
plus, this (admittedly old) page suggests this concatenation should
happen:
http://eschulte.github.io/org-scraps/scraps/2011-06-10-continued-code-blocks.html
if i evaluate (C-c C-c) "tryxx" below on the 9.1.9 which is in my emacs
(26.3), i get two lines of output (as shown). if, using packages, i
"upgrade" to either of the following:
org9.3.6 available gnu
org20200413 available org
(and, also a 201912...), i only get the first output line ("in first
tryx"). (*tangling*, i get both code blocks.)
is the behavior in the newer versions intentional? or, should i file a
bug?
cheers, and thanks. and, these days, stay safe. Greg
cut here ---
** continued code blocks
#+property: header-args :noweb yes
#+name: tryx
#+begin_src R
cat("in first tryx\n")
#+end_src
#+name: tryx
#+begin_src R
cat("in second tryx\n")
#+end_src
#+name: tryxx
#+begin_src R :results output
<>
#+end_src
#+RESULTS: tryxx
: in first tryx
: in second tryx
bug#38855: bug#38856: Odp: 26.3; org-clock-display displays 0 total time when the date is in 2020
Hello, Roberto Alejandro Rodriguez writes: > oh thanks for the tip You're welcome. I'm closing these bug reports. Regards, -- Nicolas Goaziou
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> I thought intuitively that property drawers "mostly expanded" and regular >> drawers like :LOGBOOK: drawer "mostly folded". > > There is no such thing as ":LOGBOOK:" drawers. There are property > drawers, and regular drawers. "LOGBOOK" belongs to the latter. > >>> Another (better?) option would be: "don't mess with folding state" for >>> regular drawers and blocks, i.e., what is open stays open, what is >>> closed stays closed. But that's more difficult to achieve. Any taker? >> >> This indeed will be more difficult. I agree. It's not worth to be more >> complicated. > > I think it is worth it, because it is a sane way to handle different > needs. That's will be great. > >>> In any case, I think property drawers need to be "mostly folded". >> >> In my opinion, this design is decided by the usage of properties drawers and >> other regular drawers. For now, I only used this two drawers. > > Property drawers are _internal_ to Org, which means the contents are to > be hidden. You can use property drawers, but think of them as > a database. Seeing the guts of a database is hardly useful. However, Org > provides tooling to read and write it, and even display it (e.g., Org > Colview) without having to expand them. Yes, I use it as a very tiny database. :) > You may want to expand them to edit them, or simply retrieve > information, it is all text after all, but that's not the intended use > case, so there is no incentive to expand them automatically. Sure. I have already got the new added functions. I can define a custom advice on my own Emacs init file. Thanks, Nicolas. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6cNqkUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNpcAf9FnINJuSxq5JFcBiSHzQDuZe0oZfz l6wd/rqRg7HpyVi/YJaUrQp+L+8md/YQpK+pt4+YIVWjK8Z6wpBvY0DCCtysiI2w 0MlJD7lq5Yuet+l0JsIN2lBApVaiVXaN61T2/mVdBQrTIw0mQVqiwMb8nUrBEi8q kA7UdTuwdAiP/uwtC22+lG0lRvxYfCwfulCA+zemLNvnmN5xBJwdXN9O/pdDeAcS nA0dQZYp/udkQ5EZcmkjFLRRBElCdxUqwYjiztWTuA+klGgKVzNQYo9H0mwsMo4P uyG7JnP+I8pnH43UeSMNmFiQdpM7k3fJT2xUAbkoP97ol5QVLB2e51cOCg== =02DA -END PGP SIGNATURE-
Re: Inconsistent use of \ref and \eqref in ox-latex and ox-html
Hello,
Brian Powell writes:
> Thank you for the message. I spent about 2 hours on it today learning
> more about lisp and the internals to explain your email to me.
> I learned a lot.
Thank you.
> I have modified ox-html.el to include a local OPTION as well as
> a customizable setting. I tested with both as well as with an export
> option. All three worked correctly. I also updated the org-manual.org.
>
> Please find my patch attached.
You need to provide a commit message, using git format-patch
mechanism.
> +- =HTML_EQUATION_REFERENCE_FORMAT= ::
> +
> + #+cindex: @samp{HTML_EQUATION_REFERENCE_FORMAT}, keyword
> + #+vindex: org-html-equation-reference-format
> + Specify the MathJax command for referencing equations
> + (~org-html-equation-reference-format~). The default is to wrap in
> + parentheses using "\\eqref{%s}". Setting to "\\ref{%s}" is consistent
> + with LaTeX export.
I don't think this is required. We do not document every variable for
export back-ends.
> ImageMagick suite is available on your system. You can still get this
> processing with
>
> +The command for formatting equation references can be configured via
> +~org-html-equation-reference-format~.
> +
> : #+OPTIONS: tex:dvipng
This change is odd. You insert your sentence between an explanation and
its related example. Anyway, per above, this is not needed.
However, it would be nice to reference that variable in
Publishing > Configuration > Options for the exporters > HTML specific
properties
> : #+OPTIONS: tex:dvisvgm
> diff --git a/lisp/ox-html.el b/lisp/ox-html.el
> index e70b8279b..4848028a2 100644
> --- a/lisp/ox-html.el
> +++ b/lisp/ox-html.el
> @@ -121,6 +121,7 @@
> (:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
> (:html-link-up "HTML_LINK_UP" nil org-html-link-up)
> (:html-mathjax "HTML_MATHJAX" nil "" space)
> +(:html-equation-reference-format "HTML_EQUATION_REFERENCE_FORMAT" nil
> org-html-equation-reference-format t)
> (:html-postamble nil "html-postamble" org-html-postamble)
> (:html-preamble nil "html-preamble" org-html-preamble)
> (:html-head "HTML_HEAD" nil org-html-head newline)
> @@ -761,6 +762,20 @@ The function should return the string to be exported."
>
> LaTeX
>
> +(defcustom org-html-equation-reference-format "\\eqref{%s}"
> + "MathJax command to use when referencing equations.
> +
> +Default is to wrap equations in parentheses (using \"\\eqref{%s}\)\".
It might be useful to explicitly state this is a format control string,
expecting a single argument, the actual reference.
> +Most common values are:
> +
> + \"\\eqref{%s}\"Wrap the equation in parentheses
> + \"\\ref{%s}\" Do not wrap the equation in parentheses"
> + :group 'org-export-html
> + :package-version '(Org . "9.3")
It should be "9.4".
> +;; environment. Use "ref" or "eqref" macro, depending on user
> + ;; preference to refer to those in the document.
Indentation problem?
> + (format (plist-get info :html-equation-reference-format)
> (org-export-get-reference destination info))
OK.
As a side note that you can achieve the same without this variable,
using a link filter, e.g. (untested):
(defun my-html-filter-references (text backend info)
"Change \eqref{...} into \ref{...}."
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "\\`eqref{" "ref{" text)))
(add-to-list 'org-export-filter-link-functions
'my-html-filter-references)
Anyway, would you mind sending an updated patch?
Regards,
--
Nicolas Goaziou
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
Hello, stardiviner writes: > I thought intuitively that property drawers "mostly expanded" and regular > drawers like :LOGBOOK: drawer "mostly folded". There is no such thing as ":LOGBOOK:" drawers. There are property drawers, and regular drawers. "LOGBOOK" belongs to the latter. >> Another (better?) option would be: "don't mess with folding state" for >> regular drawers and blocks, i.e., what is open stays open, what is >> closed stays closed. But that's more difficult to achieve. Any taker? > > This indeed will be more difficult. I agree. It's not worth to be more > complicated. I think it is worth it, because it is a sane way to handle different needs. >> In any case, I think property drawers need to be "mostly folded". > > In my opinion, this design is decided by the usage of properties drawers and > other regular drawers. For now, I only used this two drawers. Property drawers are _internal_ to Org, which means the contents are to be hidden. You can use property drawers, but think of them as a database. Seeing the guts of a database is hardly useful. However, Org provides tooling to read and write it, and even display it (e.g., Org Colview) without having to expand them. You may want to expand them to edit them, or simply retrieve information, it is all text after all, but that's not the intended use case, so there is no incentive to expand them automatically. Regards, -- Nicolas Goaziou
[PATCH] Fix typo in doc
Hello, I’ve spotted a small mistake in the doc. Best, -- Leo Vivier >From b2b2582b4eb1deb1a41f200a17876dfbcbf26b5e Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Sun, 19 Apr 2020 12:01:30 +0200 Subject: [PATCH] * lisp/org.el (org-mode-map): fix typo --- lisp/org-keys.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index 066720fdf..d358da763 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -219,7 +219,7 @@ ;;; Variables (defvar org-mode-map (make-sparse-keymap) - "Keymap fo Org mode.") + "Keymap for Org mode.") (defvaralias 'org-CUA-compatible 'org-replace-disputed-keys) -- 2.26.0
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> This sounds reasonable. (I deleted my patch on my local fork, I think your >> solution is better.) > > I pushed the changes. Now drawers folding is on par with blocks. You can > hide or show a drawer with `org-hide-drawer-toggle', which is similar to > `org-hide-block-toggle'. You may want to use it. I today update Org Mode source code, found this change. Thanks for your work. > > Now, visibility behaviour of drawers might be discussed. Currently, all > drawers are "mostly folded", which means that Org tries to fold them > whenever it can. OTOH, blocks are "mostly expanded", i.e., most > operations of the structure of the document opens the blocks. An > alternative would be to have property drawers "mostly folded" and > regular drawers "mostly expanded", i.e., like regular blocks. But that > would partly defeat the "tuck stuff away" feature from drawers. I thought intuitively that property drawers "mostly expanded" and regular drawers like :LOGBOOK: drawer "mostly folded". > > Another (better?) option would be: "don't mess with folding state" for > regular drawers and blocks, i.e., what is open stays open, what is > closed stays closed. But that's more difficult to achieve. Any taker? This indeed will be more difficult. I agree. It's not worth to be more complicated. > > In any case, I think property drawers need to be "mostly folded". In my opinion, this design is decided by the usage of properties drawers and other regular drawers. For now, I only used this two drawers. For properties drawer, I use them to store meta data. Like org-contacts info, and URL, Git path, Magit revision link, Author, Email, IMDb, DATE, TIME, CUSTOM_ID etc. I record those info for review in case of I want to know related info about current headline's content. For examples: - - the "DATE" property :: I want to know when I record this headline and content. - - the "AUTHOR", "EMAIL" property :: I want to know the author name and email. - - the "URL" property :: I might want to open it if I only record a part of original web page content. - - the Magit revision link :: I might want to open it when I read the Org content. About the "LOGBOOK" drawer, I usually record one log entry, or many log entries. The log entry can be multiple lines, so I can be very long. This long drawer "should be folder". Instead, the properties drawer is strict to one line as value, It will not be very long, so should "keep it expanded". This is one reason too. I just checked out insert regular drawer keybinding [C-c C-x d]. I think this should be hidden. Because it is user defined drawers, no one will know how long it is, and what purpose it is used for. And it's format similar with LOGBOOK. Not like properties drawer which has property key and value. On the other side, this properties drawer might be used by some Org related extensions, like org-contacts, org-drill etc. For org-contacts, the properties drawer should be expanded, for org-drill, this properties drawer should be hidden. At the end, I know this is just my usage experience, this should consider most Org user's habit of how to use those drawers. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6cFXQUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPCWgf9F0Za1sfg26LoCOH+gbHwlUEkCFKh 4Q6w8e1qb0Onwf7VP167WGq1ooQBkb2S4K/A8t+ZnepKjLasKM3j7x48Og4kAgCp 4aU3HN1q1z5dQKlcmPSFwTw4hmFXohQa/5+8nnKaPMZExuD427qdLtIRWKUiK7lO vwI+E0oAGroVG+auUk/iH3hxKQrd4GCVIo93nVR7pG3agR+1Ql1acuVSXmFwqhUF nO6qmiVzA2EWXaqtpWwQzagpc3hzRbqi3TP8yMaMM6nldyai5wsGFIl2LjDFF1Tk rgE9diGs2ZX+wPS+H5A/Ty97EeigPI1PjchErneZQDnEfiuclezqnJhhTA== =4m2J -END PGP SIGNATURE-
Re: wip-cite status question and feedback
"Bruce D'Arcus" writes:
> I can't see that it's necessary to have a fourth, because I think the
> result of that would be this, which doesn't make any sense.
>
> 4. "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> author-in-text+suppress-author command
>
> Let us know what you think?
I think this could sometimes make sense. Granted, it wouldn't be very
often, but if e.g. you are citing something inside a wider parenthetical
remark, like:
(Blah blah. However, Doe showed that not-blah; see her -@doe17.)
I can imagine that some style guides might forbid putting nested
parentheses in that position, so having a way to render "2017" instead
of "(2017)" would be useful.
Another case: I can imagine citation styles that use e.g. a work's title
(instead of its year) as the non-author identifier, in which case it
would often make sense to say things like
Doe depicts blah in her -@doe17
as a way to output things like
Doe depicts blah in her /Wondrous Novel/
Again, I don't know how important this is, or how widely used it would
be, but those are at least a couple of possibilities.
On the other hand, I notice that pandoc does not distinguish these
cases, at least with the default citation style; pandoc renders both
-@doe17 and [-@doe17] like "(2017)", so maybe it's not that important.
> ... notwithstanding that, I think Nicolas' latest proposed syntax
> would support this anyway.
>
> [citet:-@doe17]
Great. No objections from this corner, then!
--
Best,
Richard
Re: Inconsistent use of \ref and \eqref in ox-latex and ox-html
Nicolas,
Thank you for the message. I spent about 2 hours on it today learning more
about lisp and the internals to explain your email to me. I learned a lot.
I have modified ox-html.el to include a local OPTION as well as a customizable
setting. I tested with both as well as with an export option. All three worked
correctly. I also updated the org-manual.org.
Please find my patch attached.
Cheers,
Brian
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6d5a34e56..69a36d6c7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12531,6 +12531,15 @@ settings described in [[*Export Settings]].
to typeset LaTeX math in HTML documents. See [[*Math formatting in
HTML export]], for an example.
+- =HTML_EQUATION_REFERENCE_FORMAT= ::
+
+ #+cindex: @samp{HTML_EQUATION_REFERENCE_FORMAT}, keyword
+ #+vindex: org-html-equation-reference-format
+ Specify the MathJax command for referencing equations
+ (~org-html-equation-reference-format~). The default is to wrap in
+ parentheses using "\\eqref{%s}". Setting to "\\ref{%s}" is consistent
+ with LaTeX export.
+
- =HTML_HEAD= ::
#+cindex: @samp{HTML_HEAD}, keyword
@@ -12898,6 +12907,9 @@ files. This method requires that the dvipng program, dvisvgm or
ImageMagick suite is available on your system. You can still get this
processing with
+The command for formatting equation references can be configured via
+~org-html-equation-reference-format~.
+
: #+OPTIONS: tex:dvipng
: #+OPTIONS: tex:dvisvgm
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index e70b8279b..4848028a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -121,6 +121,7 @@
(:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
(:html-link-up "HTML_LINK_UP" nil org-html-link-up)
(:html-mathjax "HTML_MATHJAX" nil "" space)
+(:html-equation-reference-format "HTML_EQUATION_REFERENCE_FORMAT" nil org-html-equation-reference-format t)
(:html-postamble nil "html-postamble" org-html-postamble)
(:html-preamble nil "html-preamble" org-html-preamble)
(:html-head "HTML_HEAD" nil org-html-head newline)
@@ -761,6 +762,20 @@ The function should return the string to be exported."
LaTeX
+(defcustom org-html-equation-reference-format "\\eqref{%s}"
+ "MathJax command to use when referencing equations.
+
+Default is to wrap equations in parentheses (using \"\\eqref{%s}\)\".
+
+Most common values are:
+
+ \"\\eqref{%s}\"Wrap the equation in parentheses
+ \"\\ref{%s}\" Do not wrap the equation in parentheses"
+ :group 'org-export-html
+ :package-version '(Org . "9.3")
+ :type 'string
+ :safe t)
+
(defcustom org-html-with-latex org-export-with-latex
"Non-nil means process LaTeX math snippets.
@@ -3113,9 +3128,9 @@ INFO is a plist holding contextual information. See
(eq 'latex-environment (org-element-type destination))
(eq 'math (org-latex--environment-type destination)))
;; Caption and labels are introduced within LaTeX
- ;; environment. Use "eqref" macro to refer to those in
- ;; the document.
- (format "\\eqref{%s}"
+ ;; environment. Use "ref" or "eqref" macro, depending on user
+ ;; preference to refer to those in the document.
+ (format (plist-get info :html-equation-reference-format)
(org-export-get-reference destination info))
(let* ((ref (org-export-get-reference destination info))
(org-html-standalone-image-predicate
On Fri, Apr 17 2020, Nicolas Goaziou wrote:
> Hello,
>
> Brian Powell writes:
>
>> The issue is that when exporting equation numbers with ox-html, it uses
>> MathJax's \eqref that wraps the equation in parentheses, for example:
>>
>> "Refer to (3) for more."
>>
>> However, when exporting the same document with ox-latex, it uses Latex's
>> \ref that does not wrap the equation in parentheses. Would it be possible to
>> add an option or variable to ox-html for the user to select whether to use
>> \ref or \eqref on export?
>>
>> For those of us that publish to HTML and PDF, it is very difficult because
>> you end up with either double or no parentheses.
>>
>> My proposed fix would be a change to ox-html from:
>>
>>(format "\\eqref{%s}"
>>(org-export-get-reference destination info))
>>
>> to
>>
>>(format (if org-html-export-mathjax-ref "\\ref{%s}"
>> "\\eqref{%s}")
>>(org-export-get-reference destination info))
>>
>> The variable org-html-export-mathjax-ref is non-nil to use \ref vs.
>> nil to be the default \eqref.
>
> The variable could be more general, e.g.,
> org-html-export-equation-reference-format, and default to "\\ref{%s}".
> Note the export back-ends do not use variables directly. It would be
>
> (format (plist-get info :html-equation-reference-format)
> (org-export-get-reference destination info))
>
>
Public API change: How to handle function signature change gracefully
Hello everyone, I would like to change the public API of the :face part of `org-link-set-parameters': (org-link-set-parameters "file" :face 'org-link) My ultimate goal is to have org-links be able to be have their face changed based on the contents, not just the path of the link. I found the relevant code in org.el in the function `org-activate-links': 'face (pcase (org-link-get-parameter type :face) ((and (pred functionp) face) (funcall face path)) ((and (pred facep) face) face) ((and (pred consp) face) face) ;anonymous (_ 'org-link)) and would like to change this to 'face (pcase (org-link-get-parameter type :face) ((and (pred functionp) face) (funcall face path contents)) ;; this is the change ((and (pred facep) face) face) ((and (pred consp) face) face) ;anonymous (_ 'org-link)) Now that will introduce a host of call issues because the callees don't expect to the amount of arguments changed under their bottom. I would like some guidance how I could get what I think is neat: The contents of the bracket-style links as an additional parameter to set faces on and not breaking existing hookups. I'm thinking to change the above code to look at the callee's function signature and checking how many arguments it accepts and then use the right funcall for the situation. To make this more palatable I would suggest it's changed so that the 2nd argument will be a list of alists or keywords so to not have this function signature problem if someone else comes up with a reason to introduce yet more data. Thanks in advance, Benjamin Andresen
