[BUG] Cannot tangle src block in capture buffer [9.7.6]

[BUG] Cannot tangle src block in capture buffer [9.7.6]

[Dilip]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

You get ~Wrong type argument: stringp, nil~ error when you
=org-babel-tangle= on a source block in capture buffer.

To reproduce:

1. set a template
(setq org-capture-templates
'(("t" "Test" entry (file "/tmp/debug.org")
"* TODO %?\n %i\n %a")))

2. Create a source block (C-c C-, s) add :tangle header
3. Tangle it. (C-u C-c C-v C-t)

In fact,at the same time with capture buffer active if you go the file
(/tmp/debug.org) and do tangle on so far written src block it tangles
properly.

Emacs : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42, cairo version 1.18.0)
Package: Org mode version 9.7.6 (9.7.6-7a4527 @ /nix/store/w3f4jzqljh96z8axnp7fc814vg47879b-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.7.6/)

Best,
Dilip

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Ihor Radchenko]

Dilip <iDLip@protonmail.com> writes:

> You get ~Wrong type argument: stringp, nil~ error when you
> =org-babel-tangle= on a source block in capture buffer.
>
> To reproduce:
>
> 1. set a template
> (setq org-capture-templates
> '(("t" "Test" entry (file "/tmp/debug.org")
> "* TODO %?\n %i\n %a")))
>
> 2. Create a source block (C-c C-, s) add :tangle header
> 3. Tangle it. (C-u C-c C-v C-t)
>
> In fact,at the same time with capture buffer active if you go the file
> (/tmp/debug.org) and do tangle on so far written src block it tangles
> properly.

That's because capture buffer is an indirect buffer and indirect buffers
are technically not associated with any file.

We should probably fix handling indirect buffers across Org mode.

Confirmed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Derek Chen-Becker]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

On Mon, Aug 05, 2024 at 02:03:50PM +0000, Ihor Radchenko wrote:
> That's because capture buffer is an indirect buffer and indirect buffers
> are technically not associated with any file.
> 
> We should probably fix handling indirect buffers across Org mode.
> 
> Confirmed.
> 

OK, after some debugging it looks like the primary culprit is the assignment of source-file from buffer-file-name. A quick
patch seems to fix it, but I can definitely see a pattern here if org functions are trying to get the filename of the current
buffer (I can submit an official patch if this looks right):

modified   lisp/ob-tangle.el
@@ -269,7 +269,7 @@ matching a regular expression."
        (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'no-eval))))
    (user-error "Point is not in a source code block"))))
     path-collector
-            (source-file buffer-file-name))
+            (source-file (buffer-file-name (buffer-base-buffer))))
  (mapc ;; map over file-names
  (lambda (by-fn)
    (let ((file-name (car by-fn)))

There are 339 uses of buffer-file-name that I can find, but most are just bare (buffer-file-name). Are there any other cases
besides indirect buffers that we would need to handle? Would it be worth creating a new function "org-buffer-file-name" that
could properly handle indirect buffers and any other special cases, or is it just a search and replace throughout?

Cheers,

Derek

-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| http://chen-becker.org                                        |
|                                                               |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Ihor Radchenko]

Derek Chen-Becker <derek@chen-becker.org> writes:

> OK, after some debugging it looks like the primary culprit is the assignment of source-file from buffer-file-name. A quick
> patch seems to fix it, but I can definitely see a pattern here if org functions are trying to get the filename of the current
> buffer (I can submit an official patch if this looks right):
>
> modified   lisp/ob-tangle.el
> @@ -269,7 +269,7 @@ matching a regular expression."
>         (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'no-eval))))
>     (user-error "Point is not in a source code block"))))
>      path-collector
> -            (source-file buffer-file-name))
> +            (source-file (buffer-file-name (buffer-base-buffer))))
>   (mapc ;; map over file-names
>   (lambda (by-fn)
>     (let ((file-name (car by-fn)))

This looks right, yes.

> There are 339 uses of buffer-file-name that I can find, but most are just bare (buffer-file-name). Are there any other cases
> besides indirect buffers that we would need to handle? Would it be worth creating a new function "org-buffer-file-name" that
> could properly handle indirect buffers and any other special cases, or is it just a search and replace throughout?

I can think of two scenarios:

1. indirect Org buffer, as you pointed
2. a new Org buffer not yet associated with file. Even base buffer will
   then have buffer-file-name returning nil

May we have a special function? If it is going to be used 339 times,
definitely yes ;) Although, I'd prefer more telling name like
`org-base-buffer-file-name' (akin the existing `org-with-base-buffer' macro)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>