From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id OH/PHlyTWGcTHwEA62LTzQ:P1 (envelope-from ) for ; Tue, 10 Dec 2024 19:15:40 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id OH/PHlyTWGcTHwEA62LTzQ (envelope-from ) for ; Tue, 10 Dec 2024 20:15:40 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=chen-becker.org header.s=google header.b=sS4vwBC5; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1733858140; a=rsa-sha256; cv=none; b=slk0IEeRAUoWkoYhRmfW/yMACv4OqL2LlMgC3s3HlZbKRGrrnn/8FsqCP5QLsEwG37H7V8 AoIMHuHqqdPYb1f2vIEXCkbFzR4FF4MVy617YwHemDQ2LoRso5dT5QRnSxaTc95H0Extc/ nOWUXCT0ysYEBnJnSbpFt1TIsGwwNCV0b9JuZHDFtPStA5ZzBuXt/Qz7UYlpXp93xuQfCW 1T0R2V4fm10Y9OgwVUtzoyqff8GoqtZZ15k9OeTjyAgHJ5HIozDXYfA5BBCorKsQAeHjGK aMCuC/fQg49V3wWukMkdGkHhPDoLoG5Mnn/t31+eunbjGcpn8idEhzV/3aSikw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=chen-becker.org header.s=google header.b=sS4vwBC5; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1733858140; 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=fPKz4yI5c9moMSZGCs0XCsu4WGM3BhnI1Sj2fUdAdys=; b=tgkTFJ1QvPRkFMzYQr3bYMtpHz/9v667XzRR72NIChVGjGXokkBl/KXv2fM4TvNYWr7dGn 3UN+tp6VJIgIALueMM4iOmSj7VIytoFYbHOObP8XXwsGU6dAB56fj1I7Src/1hVm+efx6Y 1tGRG0OPCrhTBRp2/hnaCjAUuZeRI22Yi7A9fMk8axsFK9NRFDZtROjOc0JYug6i2XJTED oC7zjlizdH1bYxm55iTqmqaNwAltB5InpaxEfKHNziXSl65QKk1mDr3wEa8Ed5XoYtXkof 2160H1k9rEoU5J+mdQyltmV859T8ms0nuLZj2JMTlgjCMVIkOasOXSKcBhmrkw== 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 4CDA47A4D4 for ; Tue, 10 Dec 2024 20:15:40 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tL5gx-0005VF-94; Tue, 10 Dec 2024 14:14:43 -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 1tL5gv-0005TD-Fh for Emacs-orgmode@gnu.org; Tue, 10 Dec 2024 14:14:41 -0500 Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tL5gs-0001F8-MF for Emacs-orgmode@gnu.org; Tue, 10 Dec 2024 14:14:41 -0500 Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-4b11a11a4f0so420917137.3 for ; Tue, 10 Dec 2024 11:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-becker.org; s=google; t=1733858077; x=1734462877; 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=fPKz4yI5c9moMSZGCs0XCsu4WGM3BhnI1Sj2fUdAdys=; b=sS4vwBC59/Lc77th1lFnqyUFAPaEo8SwNGjbKniTfwS37VDaQgKw7Oh+oxdQQgrrTY OgDZ9iU7PxtWixU35RzhOpjKgRsSEcfCwVTIjExORw+NkLP38r872wVeNqzalsEPKKy8 y7Ha0OV4kcGoYZNSiZHUG9z9jDaMYP4ilXTLXlQbLUenRMyI+r+xpNEMQX1KcanBh5L8 pberFHrZudHTYycFkFFV0CINFtlIQxmAUz43kppY/pOvB3Yc++++/5e6g1Ga8ZARrYXP qCbYl4ngUvZGiuLcIsPWdeiUhKXaFVcNaRY/z9D0syiOvFdMnPlXzDRn/ztqefsTWx75 95iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733858077; x=1734462877; 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=fPKz4yI5c9moMSZGCs0XCsu4WGM3BhnI1Sj2fUdAdys=; b=TmVP7agN1Wtpcuxe1u5pbImoc7itaWbjta2mavqg4N69ppt+mX9kp8f9kNNESSVV81 Pu3Tvibswu7HE+NhjIcM8/4C4LiVaPGnccBrK0IIQEnF99a/PLK6T0YKlFrQsflYbwet ALxZyd4vlWBEHedw4dyOfMjnbYJWbCBZXXFWGlmSyca8doHcWwZBmNfC9fxsczGr7/uP TAi380gyRq7p/J2I7kWdKhyPitCwz6pmpBbeR8T69M0sxV3SpL8siJiw3ZoDYjqY8WtQ G4//g5FWaGlv0ob5gBkOKnQ0v2oB7a9NdCaAqc+5OLJp4ALdSM7umMiZ5SwkWymMiMtf Equg== X-Forwarded-Encrypted: i=1; AJvYcCV8s3NyEQQHc8EASboRzGx1t7E7H0rFcUAI6zU8SmYSsefrqspBo5mux6aVpvvvUufsFKuzDYLCwaBifOP3@gnu.org X-Gm-Message-State: AOJu0YwCLrbh6+isk9na5dqBxd2UFBFiEoleAsHMqD0kBRy1fqCYovz5 j3bylJQxSOwMr/YSE57ceYz3PTdUMaLvj4vj2lLC7SzlW4X44uam40oqhmLoaGs/83YusRouZqE /dC6DXdYrQoF/rFLpRlO017pWPZdvKYHgJH9N0w== X-Gm-Gg: ASbGnctroQx//MUdES2LZ/GQxAlW1wSOQrnAzeDfwo7bGQPTOHah68BEUswqzJ2ppVf YyymafRbDTd/ZSkVDL5yoXKrfqt5yxJnl X-Google-Smtp-Source: AGHT+IFfwfT5cDjkossPzZCUryL4FJnWY+TJowmSEuWhmUsF7YhAqtQBFAx5feKoQ96JMgDMnr1MkSrvpDEKtOZZobU= X-Received: by 2002:a05:6102:3752:b0:4af:eccf:e3ca with SMTP id ada2fe7eead31-4b128ff0fc0mr605296137.10.1733858077351; Tue, 10 Dec 2024 11:14:37 -0800 (PST) MIME-Version: 1.0 References: <871pyfsvnd.fsf@tilde.green> <87v7vrwgxn.fsf@localhost> In-Reply-To: <87v7vrwgxn.fsf@localhost> From: Derek Chen-Becker Date: Tue, 10 Dec 2024 12:14:26 -0700 Message-ID: Subject: Re: Contributing (looking for good first issues to tackle) To: Ihor Radchenko Cc: Dilip , Emacs-orgmode Content-Type: multipart/alternative; boundary="000000000000cac7a70628ef4a6e" Received-SPF: pass client-ip=2607:f8b0:4864:20::e33; envelope-from=derek@chen-becker.org; helo=mail-vs1-xe33.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-Queue-Id: 4CDA47A4D4 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -8.16 X-Spam-Score: -8.16 X-TUID: OXY1mLRFBeBz --000000000000cac7a70628ef4a6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Tue, Dec 10, 2024 at 11:05=E2=80=AFAM Ihor Radchenko wrote: > Derek Chen-Becker writes: > > > I would be happy to work with you on this if you're interested in > > collaborating on it. I'm a little concerned with the scope, given that > Ihor > > said: "We should probably fix handling indirect buffers across Org mode= ". > > I'm not sure how extensive indirect buffer handling is across Org, or i= f > > it's even consistent across Org right now. I'll probably need some help > > from people more familiar with it to figure out a starting point, but I= 'm > > excited to take a look :) > > You do not need to address the whole thing at once. Start by trying to > fix the exact bug described: > > 1. Try to reproduce it locally > 2. Find which part of Org code is causing the problem (you can use > edebug, M-x debug-on-entry, or modifying the code with (message ...) > or (debug) statements directly - remember that you can re-define > functions on the fly in Elisp) > 3. Try to fix it > > I wrote about "across Org mode" because my quick debugging revealed that > the problematic code might be a pattern we use in various places in > Org. So, the whole Org code base should be carefully scanned to see if > we can fix the same problem in more places. > > Such scanning usually starts from trying to regexp search code similar > to the problematic piece. In this case, AFAIR, it is simply usage of > `buffer-file-name' or `buffer-file-truename' assuming that it is never > nil. > > It is also good for you that the original bug reporter is around. Having > someone else familiar with the problem might make things easier when you > cooperate together. > > -- > 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 | +---------------------------------------------------------------+ --000000000000cac7a70628ef4a6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 s= ubmit an official patch if this looks right):

<= /div>
modified =C2=A0 lisp/ob-tangle.el
@@ -269,7 +269= ,7 @@ matching a regular expression."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'no-eval)))= )
=C2=A0 =C2=A0 (user-error "Point is not in a source code block&= quot;))))
=C2=A0 =C2=A0 =C2=A0path-collector
- =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0(source-file buffer-file-name))
+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0(source-file (buffer-file-name (buffer-base-buffer)= )))
=C2=A0 (mapc ;; map over file-names
=C2=A0 (lambda (by-fn)
= =C2=A0 =C2=A0 (let ((file-name (car by-fn)))
<= br>
There are 339 uses of buffer-file-name that I c= an find, but most are just bare (buffer-file-name). Are there any other cas= es besides indirect buffers that we would need to handle? Would it be worth= creating a new function "org-buffer-file-name" that could proper= ly handle indirect buffers and any other special cases, or is it just a sea= rch and replace throughout?

Cheers,

Derek

On Tue, Dec 10, 2024 at 11:05=E2=80=AFAM Ihor Radc= henko <yantar92@posteo.net>= ; wrote:
Derek C= hen-Becker <d= erek@chen-becker.org> writes:

> I would be happy to work with you on this if you're interested in<= br> > collaborating on it. I'm a little concerned with the scope, given = that Ihor
> said: "We should probably fix handling indirect buffers across Or= g mode".
> I'm not sure how extensive indirect buffer handling is across Org,= or if
> it's even consistent across Org right now. I'll probably need = some help
> from people more familiar with it to figure out a starting point, but = I'm
> excited to take a look :)

You do not need to address the whole thing at once. Start by trying to
fix the exact bug described:

1. Try to reproduce it locally
2. Find which part of Org code is causing the problem (you can use
=C2=A0 =C2=A0edebug, M-x debug-on-entry, or modifying the code with (messag= e ...)
=C2=A0 =C2=A0or (debug) statements directly - remember that you can re-defi= ne
=C2=A0 =C2=A0functions on the fly in Elisp)
3. Try to fix it

I wrote about "across Org mode" because my quick debugging reveal= ed that
the problematic code might be a pattern we use in various places in
Org. So, the whole Org code base should be carefully scanned to see if
we can fix the same problem in more places.

Such scanning usually starts from trying to regexp search code similar
to the problematic piece. In this case, AFAIR, it is simply usage of
`buffer-file-name' or `buffer-file-truename' assuming that it is ne= ver
nil.

It is also good for you that the original bug reporter is around. Having someone else familiar with the problem might make things easier when you cooperate together.

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