Bug: org-preview-latex-fragment fails to render in remote files (TRAMP) [8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)]

Bug: org-preview-latex-fragment fails to render in remote files (TRAMP) [8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)]

[Dustin Paluch]

Here's what DOES WORK:

Open a local org file, type in a latex fragment like "\[1 + 2 = 3\]",
then hit C-c C-x C-l. The fragment is replaced with a png as expected.


Here's what DOESN'T WORK:

Open a remote org file via C-x C-f /ssh:user@host:/path/to/file.org RET,
enter the same latex fragment, and issue the same
org-preview-latex-fragment command. The fragment will be replaced with a
blank square. Here is a gif:

http://i.imgur.com/Bb2vgWu.gif

HOWEVER! The image IS created on the remote filesystem in the adjacent
ltxpng folder as expected.

(First time sending mail from Emacs. I hope this works...)

Emacs  : GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
 of 2014-10-21 on Dustins-Macbook-Pro.local
Package: Org-mode version 8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)

current state:
==============
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe
					  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-log-done 'time
 org-latex-format-inlinetask-function 'ignore
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-support-shift-select t
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(lambda (name contents) contents)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5]
				 #[nil "\300\301\302\303\304$\207"
				   [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
				 org-babel-result-hide-spec org-babel-hide-all-hashes (lambda nil (org-indent-mode 1)))
 org-ascii-format-drawer-function '(lambda (name contents width) contents)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks
				  org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-headline-function 'ignore
 org-html-format-inlinetask-function 'ignore
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: Bug: org-preview-latex-fragment fails to render in remote files (TRAMP) [8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)]

[Nick Dokos]

Dustin Paluch <dustinpaluch@gmail.com> writes:

> Here's what DOES WORK:
>
> Open a local org file, type in a latex fragment like "\[1 + 2 = 3\]",
> then hit C-c C-x C-l. The fragment is replaced with a png as expected.
>
>
> Here's what DOESN'T WORK:
>
> Open a remote org file via C-x C-f /ssh:user@host:/path/to/file.org RET,
> enter the same latex fragment, and issue the same
> org-preview-latex-fragment command. The fragment will be replaced with a
> blank square. Here is a gif:
>
> http://i.imgur.com/Bb2vgWu.gif
>
> HOWEVER! The image IS created on the remote filesystem in the adjacent
> ltxpng folder as expected.
>
> (First time sending mail from Emacs. I hope this works...)
(it did :-) )
>

That's not a problem with org, it's a problem with images: try executing
the following two calls (with paths appropriate to your environment of
course):

(insert-image
'(image :type png :file "/scp:remote:/tmp/foo.png" :ascent center))

(insert-image
'(image :type png :file "/tmp/foo.png" :ascent center))

and you'll see the same behaviour. Try reporting it as a bug in emacs.

Nick

Re: Bug: org-preview-latex-fragment fails to render in remote files (TRAMP) [8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)]

[Rasmus]

Nick Dokos <ndokos@gmail.com> writes:

> Dustin Paluch <dustinpaluch@gmail.com> writes:
>
>> Here's what DOES WORK:
>>
>> Open a local org file, type in a latex fragment like "\[1 + 2 = 3\]",
>> then hit C-c C-x C-l. The fragment is replaced with a png as expected.
>>
>>
>> Here's what DOESN'T WORK:
>>
>> Open a remote org file via C-x C-f /ssh:user@host:/path/to/file.org RET,
>> enter the same latex fragment, and issue the same
>> org-preview-latex-fragment command. The fragment will be replaced with a
>> blank square. Here is a gif:
>>
>> http://i.imgur.com/Bb2vgWu.gif
>>
>> HOWEVER! The image IS created on the remote filesystem in the adjacent
>> ltxpng folder as expected.
>>
>> (First time sending mail from Emacs. I hope this works...)
> (it did :-) )
>>
>
> That's not a problem with org, it's a problem with images: try executing
> the following two calls (with paths appropriate to your environment of
> course):
>
> (insert-image
> '(image :type png :file "/scp:remote:/tmp/foo.png" :ascent center))
>
> (insert-image
> '(image :type png :file "/tmp/foo.png" :ascent center))
>
> and you'll see the same behaviour. Try reporting it as a bug in emacs.

But I guess we could generate the picture locally?  Or at least allow for
it.

But that's a separate bug.

—Rasmus

-- 
What will be next?

Re: Bug: org-preview-latex-fragment fails to render in remote files (TRAMP) [8.2.10 (release_8.2.10 @ /usr/local/Cellar/emacs/24.4/share/emacs/24.4/lisp/org/)]

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> But I guess we could generate the picture locally?  Or at least allow for
> it.

Done in 9e3c3ec0b357c97a488da1223f96785ec7edfc37.


Regards,

-- 
Nicolas Goaziou