[PATCH] org-preview-latex-fragment dvipng fix for packages in org-latex-packages-alist breaking 'latex' command
Abstract
This is a fix for a problem regarding the org-preview-latex-fragment
function and its associated org-preview-latex-process-alist item
'dvipng,' which is broken by imported packages from
org-latex-packages-alist which are incompatible with the 'latex'
command
Context
Relevant Org-LaTex Configurations
org-latex-packages-alist
;;Latex export commands
;;(add-to-list 'org-latex-packages-alist '("" "minted"))
(add-to-list 'org-latex-packages-alist '("margin=1in" "geometry"))
(add-to-list 'org-latex-packages-alist '("" "fancyhdr"))
(add-to-list 'org-latex-packages-alist '("" "ltablex"))
(add-to-list 'org-latex-packages-alist '("" "fontspec" t ("xelatex")))
(add-to-list 'org-latex-packages-alist '("" "xcolor"))
(add-to-list 'org-latex-packages-alist '("" "multicol"))
(add-to-list 'org-latex-packages-alist '("" "xeCJK"))
LaTex Compiler
(setq org-latex-compiler "xelatex")
Overridding Keybind
This keybind is defined in the org-mode startup hook
(local-set-key (kbd "C-c C-x C-l") 'org-latex-preview-fix)
org-preview-latex Variables
(setq org-preview-latex-default-process 'dvipng)
(setq org-preview-latex-process-alist
'(
(dvipng
: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 ("latex -interaction nonstopmode -output-directory %o %f")
:image-converter ("dvipng -D %D -T tight -o %O %f")
)
)
)
Body
The alternatives to the dvipng option in the
org-preview-latex-process-alist provided less than satisfactory
results, leaving excessive whitespace within the linked image
containing mathematics. So I wanted to pursue using dvipdf.
However, dvipng does not support PDF nor XDV which are the two
formats the my LaTex compiler outputs (xelatex). So I am forced to
use the 'latex' and 'dvipng' commands within the dvipng item of the
org-preview-latex-process-alist.
This is where my fix starts to come in. When org mode does the small
export of the latex fragment it would include the contents of
org-latex-packages-alist in the LaTex headers. Some packages (namely
'fontspec,' used for xelatex) would lead to a failure to create the
dvi file when the .tex file was compiled with the necessary
'latex' command.
To alleviate this problem I designed this wrapper function which
sets org-latex-packages-alist to nil just before executing the
org-latex-preview function.
;;Latex Preview Helper Function
(defun org-latex-preview-fix (&optional ARG)
"A wrapper function that stops org-preview from including
packages that break latex"
(interactive nil)
(let ((org-latex-packages-alist . nil))
(org-latex-preview ARG)
)
)
Now I can preview LaTex fragments without having org-mode yell at
more and not work.
Considerations
This fix is not perfect. For if you are using the xelatex compiler
and you wish to use dvipng (which in my opinion is the only option
in regard to inline maths, because of the 'tight' capabilities) with
maths that include Japanese, Chinese or other Unicode characters
requiring the 'fontspec' package, you will not be able to create
fragments.
This specific Issue however is on the conversion application side
however and from this point of view seems unfixable from org-mode's
standpoint.
Salutations
Either way, here is a relatively okay fix for a problem that I
encountered in my daily work.
Cheers!
Gabriel S. X. Smith
Re: attachments and inheritance (bug?)
I have run into this issue myself, my solution for this ended up being a quick hack to toggle this inheritence so that subheadings could reach into superheadings when referencing the same attachments. #+BEGIN_SRC elisp (defun org-attach-switch-inheritence () "Allows for Subtrees to have their own distinct attach directories" (interactive) (if (member "ID" org-use-property-inheritance) (progn (setq org-use-property-inheritance (delete "ID" org-use-property-inheritance) ) (message "ID Inheritance Disabled") ) (add-to-list 'org-use-property-inheritance "ID") (message "ID Inheritance Enabled") ) ) ;; keybinding for C-c C-A (local-set-key [3 33554433] 'org-attach-switch-inheritence) #+END_SRC Bastien writes: > Hi Julius, > > Dittmar writes: > >> Hello friends, >> >> either I misunderstood something or I stumbled upon a bug. >> >> Situation: I have a heading with some files attached. This heading has >> an ID property, upon which the directory for those files is based. >> >> There's also a subheading with no ID. Inside of that subheading I'd like >> to link to one of the attached files. But although >> org-attach-use-inheritance is non-nil, the attachment is not found from >> inside that subheading. >> >> Shouldn't it be found? > > I tried your example and the file is found for both links. > > What is the exact value of `org-attach-use-inheritance' (t or 'selective)? > > If 'selective, what is the value of `org-use-property-inheritance'? > >> - GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.10.9) of >> 2018-07-06 >> - org-mode: current master >> - no setting containing 'attach' in any configuration file > > Can you provide a reproducible recipe with a minimal configuration? > > Thanks,
Re: [PATCH] Re: Export to attach directory?
While on the topic of attachments, a low priority goal which may be nice is to have a org-attach method that allows for automatic encryption of attachments. But again, not very important Bastien writes: > Hi Eric, > > sorry for the late reply -- I don't use attachments that much > but I see how this could be useful once correctly advertized and > documented. > > Eric Abrahamsen writes: > >> Would something along these lines be considered for inclusion? > > Yes, sure, for after 9.4 -- please go ahead with a proper patch. > > Thanks,
[FEATURE REQUEST] No tangle of code blocks within archived subtrees
Context I use org-mode to configure many of my machines on my home network and use Org's tangle capability to have every configuration file be seated in the correct place. Feature Request I wish that whenever I decide that I want to completely abandon an implementation of something like networking and interface management in favor of another, that I would be able to save the previous implementation in an archive sibling subtree without this previous implementation's files being tangled. Warrants I have considered the possibility of implementing this feature in my own way so as to not inconvenience another. But after considering that even if I had designed my own wrapper function or used the pre and post tangle hooks, it would be very difficult for me to have a reliable way of stopping org-babel-tangle from tangling these specific blocks within archived subtrees short of "breaking" the code blocks with the pre hook and repairing them with the post. Even then it is a question as to how I would reliably determine which code blocks were within the archived subtree. Suggestions Since one of the issues of solving this is the inability to tell org-babel-tangle to skip code blocks by their "archivedness" but instead only by the file they are tangling or the language they are written in, I would suggest allowing the user to have the ability to configure a "tangle skip tag" or subtree property that causes org-babel-tangle to skip over blocks within that/those subtree(s). You may even wish to have an attribute that tells org-babel-tangle to skip a specific code block (via org directives, like #+NAME:). This may be more easy to implement but I am no expert on the org-babel tangling system. With this however it would be easy to build wrapper functions to disable tangling of code blocks within entire subtrees, essentially emulating the desired "archivedness" that I previously suggested. Summary This feature request being very centric as to my situation regarding the archival of code blocks within sister archive subtrees, it may seem like it would not be worth one's time to implement it. But as I have stated I see an issue with the configurability of org-babel-tangle to disregard the tangling of designated blocks and subtrees. It would benefit babel's current implementation of tangle, sitting nicely along side the "tangle based off of language" and "tangle based off of file being tangled" functionalities; also benefiting org-mode's archival functionality (as code blocks in these subtrees wouldn't interfere with non-archived code blocks) Overall, a configurable variable that allows the user to define a tag, property or a simple org directive that authoritatively dictates to org-babel-tangle what to and what not to tangle would be a welcome and fitting addition to org-mode's capabilities. Regards Thank you for your time, and of course with all this written out I still wish to say. Please forgive me if there is already a feature that solves this problem, I tried my best to dig that little bit deeper. Cheers! Gabriel Smith
