[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>

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

[Derek Chen-Becker]

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

OK, I can start working on the new function and plumb it in. I agree that
"org-base-buffer-file-name" would be better. For the case you mentioned
about an Org buffer not yet associated with a file, that seems like a
complication that we can't solve at this level. Do we leave that as a known
issue, or are there straightforward ways to maybe deal with that? It feels
like that may be case-by-case.

Thanks,

Derek

On Mon, Dec 16, 2024 at 10:37 AM Ihor Radchenko <yantar92@posteo.net> wrote:

> 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>
>


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| 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: Type: text/html, Size: 4963 bytes --]

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

[Ihor Radchenko]

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

> OK, I can start working on the new function and plumb it in. I agree that
> "org-base-buffer-file-name" would be better.

Thanks in advance!
Do note that we still cannot blindly replace every instance of
buffer-file-name with the new function. At least a cursory case-by-case
check is necessary to make sure that logic will not be broken.

> ... For the case you mentioned
> about an Org buffer not yet associated with a file, that seems like a
> complication that we can't solve at this level. Do we leave that as a known
> issue, or are there straightforward ways to maybe deal with that? It feels
> like that may be case-by-case.

It will certainly be case-by-case. Sometimes, the code can only be
evaluated in a file buffer. Ever. Sometimes not.
This one is rather theoretical.

-- 
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>