emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: suggestion to change default org-latex-pdf-process to latexmk
Date: Thu, 03 Jun 2021 09:28:49 +1000	[thread overview]
Message-ID: <87mts76dlo.fsf@gmail.com> (raw)
In-Reply-To: <1018710.1622659237@apollo2.minshall.org>

Greg Minshall <minshall@umich.edu> writes:

> Bruce,
>> > I really don't understand why the changed is needed.
>> I've stated it twice, I believe, but it's now a longer thread, so:
>> Org is set to get native citation support.
>> Once that's merged, people who use this feature will be disappointed
>> to know that when using the natbib or biblatex export processors,
>> their citations and bibliographies will not render.
>> As in, from their perspective, it will be broken upfront.
> thanks.
> one important thing will be the manual section describing the new
> capability -- it should highlight the desirability of using latexmk ("or
> some process with similar behavior"), and describe the results one will
> get without it.  presumably, people will initially need to read this
> section to figure out the syntax, etc.?
> i worry about breaking people's currently working setups.
> it seems there are N classes of users:
> 1.  not using citation engine.
> 2.  using citation engine
> 2a. ... and using default latex-to-pdf processing
> 2b. ... having customized that processing
> 2bi. ... in a way that works with new citation engine
> 2bii. .. in a way that does *not* work with new citation engine
> class 1 could likely benefit from latexmk, but it's optional.
> class 2a is probably the main class that would find it really helpful to
> have an automated latexmk.
> from *our* (the org-mode provider) point of view, i guess the 2b
> subclasses are indistinguishable.  so, if the user finds herself in
> 2bii, she will have to grep the manual or the web.  again, it would be
> good if information in the manual stuck out.  maybe a "TROUBLESHOOTING"
> sub-section for the new feature?
> i wonder if we could detect 2a, and offer them the customization dialog?
> (one would want the user to be able to click the "do not show me this
> again" button, or equivalent.)
> packaging.  :)
> cheers, Greg

My suggestion is to do something like

(defvar org-latex-pdf-process (if (executable-find "latexmk")
                                 '("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
                               '("%latex -interaction nonstopmode -output-directory %o %f"
                                 "%latex -interaction nonstopmode -output-directory %o %f"
                                 "%latex -interaction nonstopmode -output-directory %o %f")))

This is a simplistic example. It would need some refinement to work
correctly with custom, but the principal is the same. With the above,
the default would be latexmk if latexmk is installed and on the
exec-path, otherwise it will be the default latex.

We can make this as sophisticated as we want. For example, we could also
check to verify the 'default' latex is available and issue a warning to
the user if it isn't or issue a warning if none of the options are
available etc.

I believe something like the above would have the least impact as

1. It would have no impact on anyone who already sets a preference for
2. Would provide the advantages of latexmk for those who already have it
installed or once they install it (assuming no preference has been set
by the user)
3. Maintain the status quo for existing users who don't have latexmk
installed, avoiding breakage of their current setup.

Note that this is assuming that latexmk has no other 'side effects' not
raised in this thread. I don't use latexmk, so don't know precisely what
impact it would have, but based on posts from others, it would appear to
be fine. 
Tim Cross

  reply	other threads:[~2021-06-02 23:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01 15:36 Bruce D'Arcus
2021-06-01 15:52 ` Juan Manuel Macías
2021-06-01 16:36 ` Timothy
2021-06-01 16:45   ` Bruce D'Arcus
2021-06-01 17:03     ` Timothy
2021-06-01 17:41       ` Bruce D'Arcus
2021-06-02  5:33         ` Stefan Nobis
2021-06-02 15:39           ` Scott Randby
2021-06-02 16:07             ` Stefan Nobis
2021-06-02 16:29               ` Colin Baxter
2021-06-02 16:41                 ` Robert Pluim
2021-06-02 16:47                 ` Bruce D'Arcus
2021-06-02 18:40                   ` Greg Minshall
2021-06-02 23:28                     ` Tim Cross [this message]
2021-06-02 17:00                 ` Stefan Nobis
2021-06-03  5:35                   ` Colin Baxter
2021-06-02 17:36               ` Scott Randby
2021-06-02  0:00 ` Tim Cross
2021-06-02  1:09   ` Scott Randby
2021-06-02  1:25     ` Bruce D'Arcus
2021-06-02  2:56       ` Tim Cross
2021-06-02  5:27         ` Vladimir Lomov
2021-06-02  6:07   ` Stefan Nobis
2021-06-02  8:26     ` Tim Cross
2021-06-02 12:07       ` Bruce D'Arcus
2021-06-02 14:26         ` Colin Baxter
2021-06-02 22:35           ` Tim Cross
2021-06-02 15:43         ` Scott Randby
2021-06-02 16:22           ` Dr. Arne Babenhauserheide
2021-06-02 22:53             ` Tim Cross
2021-06-02 22:44           ` Tim Cross
2021-06-04 11:28             ` Dr. Arne Babenhauserheide
2021-06-02  8:40     ` Juan Manuel Macías
2021-06-02  1:09 ` Nick Dokos
2021-06-02  6:23   ` Loris Bennett

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:

  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=87mts76dlo.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: suggestion to change default org-latex-pdf-process to latexmk' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


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).