There are two new commits on the branch, addressing a couple of the
remaining items. Details below.
>>>> + ;; :processor One of dvipng, dvisvgm or imagemagick
>>>
>>> What if users add a new processor to `org-latex-preview-process-alist'
>>> and select it as default?
>>
>> I reworded it to mention org-latex-preview-process-alist.
>
> Thanks!
> There is still a related concern though.
> Currently, in the code, you check for 'dvipng/'dvisvgm symbol as
> processor and go ahead assuming that very specific command line
> parameters are passed.
There is too much logic in this library specific to dvipng, dvisvgm and
imagemagick. org-latex-preview-process-alist cannot be used for any
other image-converter program without many changes across the file. The
content of these changes will depend on the specific behavior(s) of the
new image-converter program.
One example of this specific behavior is the suffix the image-converter
program expects/uses to number images when generating several images
from a multi-page DVI. There are many others.
So I don't think it's possible to support any image-converter program
outside of these three.
> However, nothing prevents users from, say, putting dvisvgm command
> into dvipng (exaggerated example).
Users who mess with org-latex-preview-process-alist do so at their own
peril. Honestly I don't see any reason to modify it at all, except for
use with other libraries like ob-latex.
>>>> - %O placeholder in org-latex-preview-process-alist
>>>
>>> This is yet to be discussed. Pending.
I have now added support for %O to the image-converter commands. The
reason I was hesitant to add it is that the exact form depends on the
image output type, and it requires hard-coding the behaviors of dvipng,
dvisvgm and imagemagick. Your suggestion was this:
> %O is "absolute output file name"
> There is nothing stopping us from
> doing spec =
> (?O . ,(shell-quote-argument
> (concat (expand-file-name texfile-base temporary-file-directory)
> "%09d.png"))
But the suffix "%09d.png" is different for the three image converter
programs (dvipng and imagemagick can use the same format). I've now
added these special cases to org-latex-preview--create-image-async.
This means that, as mentioned above, it is not possible to drop in a new
image-converter program into org-latex-preview-process-alist and expect
it to work out of the box.
-----
I've also fixed one of the other remaining issues, of specifying a chain
of processes to org-async-call in a less awkward way. The new API is as
follows:
org-async-call accepts as its PROC argument a list where the first item
is the symbol org-async-chain, and the rest are processes to run in
sequence until one of them fails. Each process can be a string or list,
with the meanings specified above.
(org-async-call
'(org-async-chain "cmd1" "cmd2" "cmd3")
:success #'success-callback
:failure #'failure-callback
:buffer (get-buffer-create "*Output Buffer*"))
This form allows for easy specification of an async linear process
chain. In this case the SUCCESS and BUFFER arguments apply only to the
final process in the chain, and the other arguments apply to all
processes.
As a result the png path of org-babel-execute:latex -- which can call
latex thrice to generate the dvi file -- now works correctly with
org-latex-preview.
Notes on this design:
Timothy and I discussed alternatives to this, such as specifying the
list of tasks simply as a list:
(org-async-call '("cmd1" "cmd2" "cmd3") ...) ;all cmds started with
;start-process-shell-command
(org-async-call '(("ls "-la" "/tmp") ;started with start-process
"cmd2" ;with start-process-shell-command
"cmd3")
...)
But this is ambiguous as org-async-call uses a list of strings to mean
the process should be run via start-process:
(org-async-call '("ls" "-la" "/tmp") ...)
Another possibility is to change the API so that a start-process
specification uses a vector:
(org-async-call ["ls" "-la" "/tmp"] ...)
Then a list always implies a process chain, and the ambiguity is
resolved. We can have a chain of processes where some are called with
start-process:
(org-async-call '("cmd1" ["cmd2" "cmd2-arg1" "cmd2-arg2"] "cmd3") ...)
But in the end I implemented the more explicit
'(org-async-chain "cmd1" "cmd2" ...)
specification. Let me know if you have any suggestions.
-----
Since ob-latex now works with org-latex-preview, I want to ask if I can
change 'png to 'dvipng for uniformity here in ob-latex:
(defcustom org-babel-latex-process-alist
`((png :programs ("latex" "dvipng") :description "dvi > png"
:message
"you need to install the programs: latex and dvipng."
:image-input-type "dvi" :image-output-type "png"
:image-size-adjust (1.0 . 1.0) :latex-compiler
,(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"))
:image-converter ("dvipng -D %D -T tight -o %O %f")
:transparent-image-converter
("dvipng -D %D -T tight -bg Transparent -o %O %f")))
...)
To be clear, it works as-is with 'png, but using a fallback path in
org-latex-preview via org-latex-preview--generic-callback.
-----
The only remaining issues before merging are the following:
1. Removing caption support for LaTeX displaymath from ox-html breaks
use of fuzzy links in some way that I don't understand. Waiting for
Timothy to look into it as he made this change.
2. ox-odt feedback needs to be addressed.
3. Final cleanup tasks before merging:
- Rebase branch and clean up/squash some commits
- if-let -> if-let* etc
- temporary-file-directory -> (temporary-file-directory)
- Mark all org-latex-preview defcustom package versions as Org 10.0,
not Org 9.7/9.8.
- Remove test-org-latex-preview.el
- Add page breaks and section headers to org-latex-preview for
forward-page/outline-mode support
- Final byte-compile/checkdoc warning checks
Apart from your feedback on the %O and process-chain issues from above,
that's everything I have in my TODO list. If I missed something please
let me know.
Karthik
