From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19914: 25.0.50; `org-store-link' invokes function to add to `org-store-link-functions' twice Date: Sat, 21 Feb 2015 09:36:55 -0800 (PST) Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424540306 3514 80.91.229.3 (21 Feb 2015 17:38:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Feb 2015 17:38:26 +0000 (UTC) To: 19914@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 21 18:38:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YPE0J-0005Q8-8u for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Feb 2015 18:38:11 +0100 Original-Received: from localhost ([::1]:36880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPE0I-0003lS-Hc for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Feb 2015 12:38:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPE0E-0003kL-K3 for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:38:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPE0B-0000f7-5U for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:38:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPE0B-0000ez-1B for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:38:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YPE0A-0003uN-Nk for bug-gnu-emacs@gnu.org; Sat, 21 Feb 2015 12:38:02 -0500 X-Loop: help-debbugs@gnu.org 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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.142454023214956 (code B ref -1); Sat, 21 Feb 2015 17:38:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 21 Feb 2015 17:37:12 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99679 Archived-At: 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'