Greg Minshall <minsh...@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
org-latex-pdf-process
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
