From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id yAPaGJ5eZGd3HwAA62LTzQ:P1 (envelope-from ) for ; Thu, 19 Dec 2024 17:57:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id yAPaGJ5eZGd3HwAA62LTzQ (envelope-from ) for ; Thu, 19 Dec 2024 18:57:50 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=chen-becker.org header.s=google header.b="hbw//qGe"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734631070; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ZRuJ4SmFD1gSiL3RGAcit8aCMAOQRWlUJHApdzfGQVA=; b=HFfvJgWOzsnXrOMHYIx1CegLJnOQ4VEKXmHF9m4xf65HiXfrhLxcwbi8UAEjYEUg6avXMx PYSfA1Tb0Zkmm5L75yB9FJ5D7fz8OIQK2k2JOpoVPqwxfVO3bK3YvDtArUUyPSuC+yL0et +eE2rwnfbKro3t+hukf1niP+3sMNtq/6YJBICiKQ54vrN6qsowNDB1SmOWEIYQUZl61Zle 1qebq6ELUPomvFiF/kb3cgNA6tAbMzs+TTSRexwdCeFTT3M6qT+dYqlEe4ajt4hIehmJ6y TtxAkOnmJipQbk9hbWmxbWWXz5prt4ePMglJXfmY4rW7b0CWqSOwQ++oYyJiaQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=chen-becker.org header.s=google header.b="hbw//qGe"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734631070; a=rsa-sha256; cv=none; b=dDi+u5MHgAs0/j5f3+NpUJi/7hSiEj4IrZ0pObCuTZZRFp1qKI9amOu5Cr63QrBOZYOtbj mXJ4pbOZB++uMFxr+WzXLvYb1UTTRyxlb5Z9khuAzaPh/zv1AXIEEPpOYzGOcAzra/Ydx5 ILnZVxliNhRX76a+WgLftvQ8XFkhfa0I4KWUuYpaZYO3LLruUg12DPHmkwiufkOV7Hl11R YwMtjKiel2PPK/+RBW96rYsjM8OLrBW3GNwyCMMIh2A8pNeuYYKS7KtncjnI7PKxzY4Mpk 7M8WXmVSWtAdeoweaK0v/YBKaxbVExhtKsvz5V79Pb9V7Yjp7Knui/aXjJiHRg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2264966F4 for ; Thu, 19 Dec 2024 18:57:49 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOKlm-0005d9-UA; Thu, 19 Dec 2024 12:57:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOKlk-0005Zu-Jp for emacs-orgmode@gnu.org; Thu, 19 Dec 2024 12:57:04 -0500 Received: from mail-vk1-xa2c.google.com ([2607:f8b0:4864:20::a2c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOKlh-00053G-Pa for emacs-orgmode@gnu.org; Thu, 19 Dec 2024 12:57:04 -0500 Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-518ae5060d4so328352e0c.0 for ; Thu, 19 Dec 2024 09:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-becker.org; s=google; t=1734631019; x=1735235819; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZRuJ4SmFD1gSiL3RGAcit8aCMAOQRWlUJHApdzfGQVA=; b=hbw//qGe1UC29JRXEg7XpfmwUz5jF4cZBOXBA/rGyzJ8nQ0WPAACJeVwxik8ioDavt EgpUM4p9NHvvWHCfuxsoo6k0wWln4Yd6YZIhzJU0KY107tjwqSVbCZksFwYwXaaEuN+a QfaodfVeBkQEbVP6JsjUoixJYGY8APOaj8b7p8LlYTAoTYLnTqOE0yH4duD+1PPZ0FkI lrmgyiTSvxldhUB4MGK5yu016sbGYtMRCPirEWGRjT4AWNMHKLX6BRMeMQKBplT5Qbx9 LixCNmB7qS4sMZ1fU9yjuTdKRisR2harc8tL+fFlSbCZvXENhJkW8ICyS1UauGPU/BQ4 tXmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734631019; x=1735235819; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZRuJ4SmFD1gSiL3RGAcit8aCMAOQRWlUJHApdzfGQVA=; b=ZnpFX6tzHeiCsPrcuI6ezdAyeN/BlHdmL/iWHQAFA0CwexRa9pWvg6+O5YB93rskIx bFXnEI2MaUdXpuV8bOWqAbjBpfyhvmyhdZvM0xVQyAzD8O9wWrju+nzkiugu72KnOZNE eRjxqv4T+Hn8FiWc2OK6pGsQ9E2Fsdx+D1K/fpnd0rKYkNW5N01XyDtmvWVigGo0Z/yU xqXSGOb743R0jdVUuznsr+zCol+t0AYjfnvBten4p8cpLLsXAO7fmwFNzZa4PVxXe2Cq UsT859G5ZKFiIj9ZXz7zbQ3cKm+rJQ+uRoO11ZPrtQ1zoW1+kCQ9oHf7UhYjqhUbhM9y BW0Q== X-Gm-Message-State: AOJu0YznU0pFIfyWjwPN9u1KAWxLvfrTFwY7Ytm5KNJ/lW1LvpzNw6b3 X8t/z11wi3ewcZtW3WogYLsUy/TEdW/NaGxO1oTo90YpKEq8DHO2byKrspNqSqWHgoGY8G71WQL jMBo12jtseA5CeARbJakeO92pocglDx6BUM0RlO+44I6oNbKL X-Gm-Gg: ASbGncukqi9FdeCR1zdLOQeI/KDhvOZ6bopbSocmMqniB4B9ndYoxd7zxwLde8zagqz oRBgLfdXMhNYfiSQkJw08n9rOo3QUGi5N9YThVrUO X-Google-Smtp-Source: AGHT+IExMT3av+r/Mr+doU2Feulr/fd85DpMXeLwpA4+fjAEwYi9xKm18E75HDHp2B6PT20j+OuUEBTiTobAzRT3ywI= X-Received: by 2002:a05:6122:1688:b0:515:d38a:e168 with SMTP id 71dfb90a1353d-51a36c70b0amr8331714e0c.4.1734631019130; Thu, 19 Dec 2024 09:56:59 -0800 (PST) MIME-Version: 1.0 References: <2dijBN1CGUPtmZzcNXZAe54y8u0pC8V_DYIBCL4rSR1eh2s8TFJGW5V3q7pkiCRFtEHYXy66CU7F6kK3NN_VAX-R_RbAXptG0b5vOlUQsi8=@protonmail.com> <87y15bcbi1.fsf@localhost> <877c7zede2.fsf@localhost> In-Reply-To: <877c7zede2.fsf@localhost> From: Derek Chen-Becker Date: Thu, 19 Dec 2024 10:56:48 -0700 Message-ID: Subject: Re: [BUG] Cannot tangle src block in capture buffer [9.7.6] To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="000000000000b651fc0629a3410d" Received-SPF: pass client-ip=2607:f8b0:4864:20::a2c; envelope-from=derek@chen-becker.org; helo=mail-vk1-xa2c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -6.22 X-Spam-Score: -6.22 X-Migadu-Queue-Id: 2264966F4 X-TUID: vVdb5vI9ZuvE --000000000000b651fc0629a3410d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ihor Radchenko wrote: > Derek Chen-Becker 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 wort= h > 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 . > Support Org development at , > or support my work at > --=20 +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=3Dderek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+ --000000000000b651fc0629a3410d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I can start working on the new func= tion and plumb it in. I agree that "org-base-buffer-file-name" wo= uld be better. For the case you mentioned about an Org buffer not yet assoc= iated with a file, that seems like a complication that we can't solve a= t this level. Do we leave that as a known issue, or are there straightforwa= rd ways to maybe deal with=C2=A0that? It feels like that may be case-by-cas= e.

Thanks,

Derek

On Mon, Dec 16, 2024 at 10:37=E2=80=AFAM 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 assi= gnment 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=C2=A0 =C2=A0lisp/ob-tangle.el
> @@ -269,7 +269,7 @@ matching a regular expression."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or (cdr (assq :tangle (nth 2 (org-ba= bel-get-src-block-info 'no-eval))))
>=C2=A0 =C2=A0 =C2=A0(user-error "Point is not in a source code blo= ck"))))
>=C2=A0 =C2=A0 =C2=A0 path-collector
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (source-file buffer-file-na= me))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (source-file (buffer-file-n= ame (buffer-base-buffer))))
>=C2=A0 =C2=A0(mapc ;; map over file-names
>=C2=A0 =C2=A0(lambda (by-fn)
>=C2=A0 =C2=A0 =C2=A0(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 j= ust bare (buffer-file-name). Are there any other cases
> besides indirect buffers that we would need to handle? Would it be wor= th 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
=C2=A0 =C2=A0then 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= 9; 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-Bec= ker=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
| GPG Key available at https://= keybase.io/dchenbecker = and=C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7=C2=A0 7F42 AFC5 AFEE 96E4 6ACC= =C2=A0 |
+------------= ---------------------------------------------------+

<= /div>
--000000000000b651fc0629a3410d--