result files with leading `../../../`, and HTML preview with ~/ in filenames

[adl]

I'm looking forward to use org-msg to inline pictures of automata in my email. However currently I'm encountering a strange issue:

If I enter

#+begin_src dot :exports results :file test.png
  digraph {
      a -> b
      b -> c
  }
#+end_src

and type C-c C-c on it, org will generate test.png in the current directory (which is my home), and it will then insert

#+RESULTS:
[[file:../../../test.png]]

This is a link I cannot follow (typing Enter on it yield "File not found and directory write-protected") I would have to edit the filename in order to view it inside emacs.

When I type C-c C-e to preview the HTML file, I cannot see the picture either. The HTML file passed to firefox contains <img src="~/test.png" alt="test.png"> but I don't think firefox will understand ~/.

When I send the email both [[file:../../../test.png]] and [[file:test.png]] seem to work fine.

[jeremy-compostella]

This is a link I cannot follow (typing Enter on it yield "File not found and directory write-protected") I would have to edit the filename in order to view it inside Emacs.

Up to here I reproduce the issue except that I don't get any error when I try to access to the file using org-open-at-point but the image does not show up. That's something I noticed sometimes but which has stay low priority.

When I type C-c C-e the preview work in firefox and the img tag looks like <img src="/home/jcompost/test.png" alt="test.png"/>. I investigated and by forcing my default directory to ~, I am able to reduce this behavior. I have improved the org-msg-html-buffer-to-xml get-file-path() function local function to take care of this.

After investigation, I figured out that the reason for this weird path is that the buffer file is in the user mail draft directory which is different than the buffer-local default-directory. It makes the org-babel-result-to-file following code generate this surprising path:

              (file-relative-name
               (expand-file-name result default-directory)
               (file-name-directory (buffer-file-name)))

I was thinking that we could set the default-directory to the buffer-file-name directory. With this change it does work but it creates a disconnect in the behavior with and without org-msg-edit-mode. I don't know what is the best solution yet and I have too much high priority items to work on as I write these lines.

[adl]

Thank you for investigating. Looking at the org-babel-result-to-file function, it would seem one solution is simply to (setq-local org-link-file-path-type 'absolute) while setting up the composition buffer?

[jeremy-compostella]

Sorry for the delay. I have been very busy lately. I agree that this is likely the simplest solution and I have implemented it. It seems that this issue should be resolved on the experimental branch. Let me know if it also work for you.

[jeremy-compostella]

Did you get a chance to test the patches ?

[adl]

I just did. Generating inline images with org-babel now works without problem in the composition buffer, and the image are correctly inlined in the sent email. So this issue seem solved.

However while testing it, I discovered that SVG files seem broken in the output.

To reproduce, construct an email with:

#+begin_src dot :exports results :file test.png
  digraph {
      a -> b
      b -> c
  }
#+end_src

#+begin_src dot :exports results :file test.svg
  digraph {
      a -> b
      b -> c
  }
#+end_src

Type C-c C-c on both blocks before sending the email. In the resulting email, the test.png is attached, while the test.svg is inlined. I was unable to view the inlined SVG in either gmail or gnus (but displaying the HTML part externally with gnus-article-browse-html-article worked).

I wonder if there is a way to disable inlining of SVG images and simply attach them like other images? This would also makes more sense for the text/plain part, which contains:

<file:test.png>

<file:test.svg>

[jeremy-compostella]

The experimental branch should take care of this last issue. Could you test it ?