I cannot seem to be able to make org-babel-tangle respect the setting of org-babel-tangle-use-relative-file-links to t. Here is my process after launching "emacs -Q" (the default for org-babel-tangle-use-relative-file-links appears to be true in this configuration): 1. Write example org file named test.org with the following basic contents, making sure that the top line is refreshed with C-c C-c: #+PROPERTY: header-args :tangle test.py :comments link * My top level Here is my description #+BEGIN_SRC python print("This is my code") #+END_SRC 2. Run M-x org-babel-tangle on the org file, which produces test.py with the following contents: # [[file:d:/mytest/test.org::*My%20top%20level][My top level:1]] print("This is my code") # My top level:1 ends here As can be seen in the first line, it uses an absolute file path containing my org file and py file, rather than the expected relative one. I looked through the ob-tangle.el file to try and see why this is the case, and it looks like there's some negative boolean result in this if statement in the org-babel-tangle-single-block function which causes it to skip over the code that would make use of the relative path: (if (and org-babel-tangle-use-relative-file-links (string-match org-link-types-re link) (string= (match-string 0 link) "file")) (on the online copy of the code, this is the region under consideration: https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-tangle.el#L475 I have not yet tried the most recent development copy because I do not see considerable difference in the relevant lines compared to the version of ob-tangle.el I have, but I can try the development copy as a next step) Here is the additional bug reporter output, on my Windows 10 64 bit computer. Emacs : GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29 Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ c:/Useful Programs/emacs-26.3-x86_64/share/emacs/26.3/lisp/org/)
With some further testing regarding the issue, I have been able to replicate the problem, with the relative links setting in org babel being ignored, using "emacs -Q" on Ubuntu with the emacs version installed from their package repository. The test.org file is the same as before, and again the absolute path of the folder being shown in the link comments in the output test.py file: # [[file:~/mytest/test.org::*My%20top%20level][My top level:1]] print("This is my code") # My top level:1 ends here Here is the bug report system info: Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/) I was also able to replicate the problem using the bleeding edge version of org mode, with the same absolute path result as above. The bug report system info reports this org mode version: Package: Org mode version 9.3.7 (release_9.3.7-627-g0eeee1 @ /home/test/elisp/org-mode/lisp/) Let me know if I can provide any further information, thank you very much for your help.
Jeremias Gonzalez writes: > I cannot seem to be able to make org-babel-tangle respect the setting of > org-babel-tangle-use-relative-file-links to t. Here is my process after > launching "emacs -Q" (the default for > org-babel-tangle-use-relative-file-links appears to be true in this > configuration): [...] > I looked through the ob-tangle.el file to try and see why this is the > case, and it looks like there's some negative boolean result in this if > statement in the org-babel-tangle-single-block function which causes it > to skip over the code that would make use of the relative path: > > (if (and org-babel-tangle-use-relative-file-links > (string-match org-link-types-re link) > (string= (match-string 0 link) "file")) Thank you for the excellent bug report. This is should be fixed by 3ebee0331.
Kyle Meyer writes:
> Thank you for the excellent bug report. This is should be fixed by
Guh, "is should be". Apparently I started off feeling bold,
reconsidered, and then did a sloppy job of switching to a more cautious
claim :/
On 6/8/2020 5:37 PM, Kyle Meyer wrote:
> Kyle Meyer writes:
>
>> Thank you for the excellent bug report. This is should be fixed by
>
> Guh, "is should be". Apparently I started off feeling bold,
> reconsidered, and then did a sloppy job of switching to a more cautious
> claim :/
The new code works perfectly for me on both my test systems, your
boldness was justified:) Thank you very much for the fix.