From unknown Mon Aug 11 12:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19914: 25.0.50; `org-store-link' invokes function to add to `org-store-link-functions' twice Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Feb 2015 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 19914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 19914@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.142454023214956 (code B ref -1); Sat, 21 Feb 2015 17:38:02 +0000 Received: (at submit) by debbugs.gnu.org; 21 Feb 2015 17:37:12 +0000 Received: from localhost ([127.0.0.1]:50362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPDzL-0003t9-Cg for submit@debbugs.gnu.org; Sat, 21 Feb 2015 12:37:11 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55222) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPDzI-0003t0-V8 for submit@debbugs.gnu.org; Sat, 21 Feb 2015 12:37:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPDzH-0008K7-HE for submit@debbugs.gnu.org; Sat, 21 Feb 2015 12:37:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPDzH-0008Jz-F9 for submit@debbugs.gnu.org; Sat, 21 Feb 2015 12:37:07 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPDzG-0003h0-Bg for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:37:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPDzA-0008FH-M2 for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:37:06 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:20639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPDzA-0008ER-Ff for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:37:00 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1LHawKJ018056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 Feb 2015 17:36:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1LHavnx015911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 21 Feb 2015 17:36:58 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1LHav6f011621 for ; Sat, 21 Feb 2015 17:36:57 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 21 Feb 2015 09:36:55 -0800 (PST) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) I'm no expert on this, so PLEASE CORRECT ME if I'm mistaken. See this code in `org-store-link': ((and (not (equal arg '(16))) ; Store a link using an external link type (setq sfuns (delq nil (mapcar (lambda (f) (let (fs) (if (funcall f) (push f fs)))) ; #1 org-store-link-functions)) sfunsn (mapcar (lambda (fu) (symbol-name (car fu))) sfuns)) (or (and (cdr sfuns) (funcall (intern (completing-read "Which function for creating the link? " sfunsn nil t (car sfunsn))))) (funcall (caar sfuns))) ; #2 (setq link (plist-get org-store-link-plist :link) desc (or (plist-get org-store-link-plist :description) link)))) Consider a function `foo' in `org-store-link-functions'. It should return non-nil if it actually does its link-defining thing in the given context, i.e., if it is applicable there. In #1 above, it is apparently called merely to test whether it applies. If so then it is made a member of SFUNS. Assume that it applies and it is the only such function that applies (i.e., SFUNS is a singleton), for simplicity. Then its name is made a member of SFUNSN. So `foo' then gets invoked again (#2). This means that it will have done its thing TWICE: once just to check whether it should/could do its thing and another time so that it does its thing. That is, it seems that the point of the first AND clause is only to determine which functions in `org-store-link-functions' are to be candidates for invocation (have their names added to SFUNSN). And it seems that the point of the second AND clause is to invoke one of them. That means that the one that is chosen to be invoked gets invoked twice. (This is so even if SFUNS is not a singleton.) Why invoke the chosen function twice? This could be costly. Or it might be annoying, if the function interacts with a user. Or it might be incorrect, if the function has side effects. (And why the dance between the function and its name? Is that really needed? Seems like the name is used only for `completing-read', which might not even be invoked.) This logic seems a bit convoluted to me. That might well be a sign that I'm missing something - please let me know. And what is the point of this function, which is mapped over SFUNS: (lambda (f) (let (fs) (if (funcall f) (push f fs)))) That seems the same as (lambda (f) (and (funcall f) (list f))). IOW, that seems only to return (list f) if invoking f returns non-nil (and nil otherwise). Why bother to `push' to a local variable that is otherwise unused? What am I missing? (This is not important to the bug, unless I misunderstand completely.) If I have a function `foo' on `org-store-link-functions', and if that function does something non-trivial or non-idempotent when its test for applicability succeeds, then I need to find some way to separate the part of it that simply tests whether it is applicable (returning non-nil if yes) from the part that actually defines the link. How to do that? I could try to record some state and do one or the other part alternately, each time `foo' is invoked. But then I would need to handle possible interruptions (e.g. C-g) etc. that might throw things off - getting the recorded state out of sync with the actual state. That's fragile and ugly. This logic seems quite weird to me. Please let me know what I'm missing, or whether this is indeed something that needs to be fixed in `org-store-link'. And in the latter case, please suggest a reasonable workaround for use with the pre-bugfix (i.e., the current) logic: how to code a function `foo' so that the first invocation just returns non-nil when `foo' is applicable and the second invocation does the actual link definition. I will need that to let my code to work with pre-bugfix versions of org.el. In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2014-10-20 on LEG570 Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --enable-checking=3Dyes,glyphs CPPFLAGS=3D-DGLYPH_DEBUG=3D1' From unknown Mon Aug 11 12:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19914: 25.0.50; `org-store-link' invokes function to add to `org-store-link-functions' twice Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Feb 2015 18:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 19914@debbugs.gnu.org Received: via spool by 19914-submit@debbugs.gnu.org id=B19914.142454167117175 (code B ref 19914); Sat, 21 Feb 2015 18:02:01 +0000 Received: (at 19914) by debbugs.gnu.org; 21 Feb 2015 18:01:11 +0000 Received: from localhost ([127.0.0.1]:50368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPEMY-0004Sx-UQ for submit@debbugs.gnu.org; Sat, 21 Feb 2015 13:01:11 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:36583) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPEMX-0004Sp-1f for 19914@debbugs.gnu.org; Sat, 21 Feb 2015 13:01:09 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1LI16b1032643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <19914@debbugs.gnu.org>; Sat, 21 Feb 2015 18:01:08 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1LI16kr004652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <19914@debbugs.gnu.org>; Sat, 21 Feb 2015 18:01:06 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1LI151h004637 for <19914@debbugs.gnu.org>; Sat, 21 Feb 2015 18:01:05 GMT MIME-Version: 1.0 Message-ID: <99056495-17e4-4cc4-86e7-9e506f2a100c@default> Date: Sat, 21 Feb 2015 10:01:03 -0800 (PST) From: Drew Adams References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > This means that it will have done its thing TWICE: once just to check > whether it should/could do its thing and another time so that it does > its thing. Also, the doc of `org-store-link-functions' says nothing about the function being called twice. It says only: "Each function should check if it is responsible for creating this link (for example by looking at the major mode). If not, it must exit and return nil. If yes, it should return a non-nil value after a calling `org-store-link-props' with a list of properties and values." (And "a calling" is a typo - it should be "calling".) This doc is essentially a spec telling you what a function for this list should do. From the doc, its purpose is to (a) check whether it should call `org-store-link-props' and (b) if so, call it and return non-nil, else return nil (without calling it). Nothing suggests that the function, if invoked to define a link, will be invoked twice: once for (a) (even though (b) will also be done then) and a second time for (b). --- Also wrt the doc: The functions on `org-store-link-functions' do not really "create and store a link", AFAICT. They merely define a link. It is `org-store-link' that uses this definition to create and store a link. The most that these functions do is invoke `org-store-link-props', and that neither creates nor stores a link. Whether you think of "creating" a link as inserting it somewhere or just adding it to `org-stored-links' (in which case "creating" the link is synonymous with "storing" it), the functions on `org-store-link-functions' do not, themselves, update `org-stored-links'. Putting a link on that list is the only thing that could reasonably be considered "storing" a link, AFAICT. (Hence the name of function `org-store-link'.) From unknown Mon Aug 11 12:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19914: 25.0.50; `org-store-link' invokes function to add to `org-store-link-functions' twice Resent-From: Nicolas Goaziou Original-Sender: "Debbugs-submit" Resent-CC: emacs-orgmode@gnu.org Resent-Date: Fri, 01 Dec 2017 18:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19914 X-GNU-PR-Package: org-mode X-GNU-PR-Keywords: To: Drew Adams Cc: 19914@debbugs.gnu.org Received: via spool by 19914-submit@debbugs.gnu.org id=B19914.151215401223403 (code B ref 19914); Fri, 01 Dec 2017 18:47:01 +0000 Received: (at 19914) by debbugs.gnu.org; 1 Dec 2017 18:46:52 +0000 Received: from localhost ([127.0.0.1]:40404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKqKq-00065P-Kf for submit@debbugs.gnu.org; Fri, 01 Dec 2017 13:46:52 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:48552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKqKn-00065G-Ud for 19914@debbugs.gnu.org; Fri, 01 Dec 2017 13:46:50 -0500 Received: from saiph.selenimh (000043010000000000000469.ipv6.commingeshautdebit.fr [IPv6:2a03:a0a0:0:4301::469]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id B4F98C5A5F; Fri, 1 Dec 2017 19:46:48 +0100 (CET) Received: from ngz by saiph.selenimh with local (Exim 4.89) (envelope-from ) id 1eKqKm-0000Jl-53; Fri, 01 Dec 2017 19:46:48 +0100 From: Nicolas Goaziou In-Reply-To: <99056495-17e4-4cc4-86e7-9e506f2a100c@default> (Drew Adams's message of "Sat, 21 Feb 2015 10:01:03 -0800 (PST)") References: <99056495-17e4-4cc4-86e7-9e506f2a100c@default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Date: Fri, 01 Dec 2017 19:46:48 +0100 Message-ID: <87h8taguav.fsf@nicolasgoaziou.fr> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, Drew Adams writes: >> This means that it will have done its thing TWICE: once just to check >> whether it should/could do its thing and another time so that it does >> its thing. > > Also, the doc of `org-store-link-functions' says nothing about the > function being called twice. It says only: > > "Each function should check if it is responsible for creating > this link (for example by looking at the major mode). > If not, it must exit and return nil. > If yes, it should return a non-nil value after a calling > `org-store-link-props' with a list of properties and values." > > (And "a calling" is a typo - it should be "calling".) > > This doc is essentially a spec telling you what a function for this > list should do. From the doc, its purpose is to (a) check whether > it should call `org-store-link-props' and (b) if so, call it and > return non-nil, else return nil (without calling it). > > Nothing suggests that the function, if invoked to define a link, > will be invoked twice: once for (a) (even though (b) will also be > done then) and a second time for (b). This function no longer invokes twice the function used to create the link. Thank you. Regrads, -- Nicolas Goaziou 0x80A93738 From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 01 13:47:46 2017 Received: (at control) by debbugs.gnu.org; 1 Dec 2017 18:47:46 +0000 Received: from localhost ([127.0.0.1]:40408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKqLh-000674-Vv for submit@debbugs.gnu.org; Fri, 01 Dec 2017 13:47:46 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKqLf-00066s-Nh for control@debbugs.gnu.org; Fri, 01 Dec 2017 13:47:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKqLZ-000593-Sw for control@debbugs.gnu.org; Fri, 01 Dec 2017 13:47:38 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKqLZ-00058z-PY for control@debbugs.gnu.org; Fri, 01 Dec 2017 13:47:37 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1eKqLZ-0000Qr-HH for control@debbugs.gnu.org; Fri, 01 Dec 2017 13:47:37 -0500 Subject: control message for bug 19914 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Fri, 01 Dec 2017 13:47:37 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) close 19914 From unknown Mon Aug 11 12:55:03 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19914: 25.0.50; `org-store-link' invokes function to add to `org-store-link-functions' twice Resent-From: Nicolas Goaziou Original-Sender: "Debbugs-submit" Resent-CC: emacs-orgmode@gnu.org Resent-Date: Fri, 01 Dec 2017 20:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19914 X-GNU-PR-Package: org-mode X-GNU-PR-Keywords: To: Drew Adams Cc: 19914-done@debbugs.gnu.org Received: via spool by 19914-done@debbugs.gnu.org id=D19914.151216192218141 (code D ref 19914); Fri, 01 Dec 2017 20:59:02 +0000 Received: (at 19914-done) by debbugs.gnu.org; 1 Dec 2017 20:58:42 +0000 Received: from localhost ([127.0.0.1]:40590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKsOQ-0004iX-HU for submit@debbugs.gnu.org; Fri, 01 Dec 2017 15:58:42 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:50680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKsOO-0004iN-BC for 19914-done@debbugs.gnu.org; Fri, 01 Dec 2017 15:58:40 -0500 Received: from saiph.selenimh (000043010000000000000469.ipv6.commingeshautdebit.fr [IPv6:2a03:a0a0:0:4301::469]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C7EDB17209B; Fri, 1 Dec 2017 21:58:38 +0100 (CET) Received: from ngz by saiph.selenimh with local (Exim 4.89) (envelope-from ) id 1eKsOL-0000Uw-MJ; Fri, 01 Dec 2017 21:58:37 +0100 From: Nicolas Goaziou In-Reply-To: <87h8taguav.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Fri, 01 Dec 2017 19:46:48 +0100") References: <99056495-17e4-4cc4-86e7-9e506f2a100c@default> <87h8taguav.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Date: Fri, 01 Dec 2017 21:58:37 +0100 Message-ID: <87374uf9mq.fsf@nicolasgoaziou.fr> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Nicolas Goaziou writes: > Hello, > > Drew Adams writes: > >>> This means that it will have done its thing TWICE: once just to check >>> whether it should/could do its thing and another time so that it does >>> its thing. >> >> Also, the doc of `org-store-link-functions' says nothing about the >> function being called twice. It says only: >> >> "Each function should check if it is responsible for creating >> this link (for example by looking at the major mode). >> If not, it must exit and return nil. >> If yes, it should return a non-nil value after a calling >> `org-store-link-props' with a list of properties and values." >> >> (And "a calling" is a typo - it should be "calling".) >> >> This doc is essentially a spec telling you what a function for this >> list should do. From the doc, its purpose is to (a) check whether >> it should call `org-store-link-props' and (b) if so, call it and >> return non-nil, else return nil (without calling it). >> >> Nothing suggests that the function, if invoked to define a link, >> will be invoked twice: once for (a) (even though (b) will also be >> done then) and a second time for (b). > > This function no longer invokes twice the function used to create the > link. Closing this bug.