avoid org-preview-latex to open a new window

Question

I use emacs in frame-only mode and org to typeset latex equations and technical writing.

Since it is hard to see and understand the latex equations in their raw format, I use a package called org-fragtog which just calls the function org-latex-preview to convert the latex code to an image, and insert it in the current buffer.

The problem is, every time a new equation is inserted for the first time, org-latex-preview calls dvipng which opens a new window with the message:

"This is dvipng 1.16 Copyright 2002-2015, 2019 Jan-Ake Larsson [1] ".

Is there a way to suppress this window to open in the first place, or to make it open only when there is an error?

When you are creating lots of equations in a row this gets in the way and stops the flow.

Update

While not knowing a lot of elisp, I could craft the function below. The only problem is it is not being called after org-latex-preview is executed. Anyone know why?

(defun kill-latex-preview-window ()
  (interactive
  (let ((buffer "*Org Preview LaTeX Output*"))
    (if (get-buffer buffer)
        (progn
        (delete-frame (select-frame-by-name buffer))
        (kill-buffer buffer)
        )
    )
  )
  )
)

(add-hook 'post-command-hook 'kill-latex-preview-window )

Answer 1

Probably the simplest thing to do is to define your own preview function that locally redefines the function that pops up the buffer so that it does nothing, then redo the key binding so that it calls your function instead:

(defun my-org-latex-preview ()
  (interactive)
  (cl-letf (((symbol-function 'display-message-or-buffer) (lambda (msg) nil)))
    (org-latex-preview)))

(define-key org-mode-map (kbd "C-c C-x C-l" 'my-org-latex-preview)

Since it's a local redefinition it is unlikely to cause any problems, except in the case where you really want to see that buffer (e.g. in case of errors), but then you can switch to it manually: the buffer is still around, it is just not popped up.

I see also that you opened an issue which was a good thing to do: at the very least, they should know about the problem, but there may be a less hackish solution too (or they might implement one).

Answer 2

Thanks to everyone who helped.

I contacted the package author which corrected the bug.

The solution is detailed on commit 67de558 and issue 32.

It basically added the function org-compile-file to the list of functions that are blacklisted in frames-only-mode in the function frames-only-mode-use-window-functions. This way, every time the function is called it only opens a window, and not a frame.