From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Adesam Subject: org-store-link calls external link type store functions twice? Date: Tue, 7 May 2013 21:51:37 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=e89a8f5037922b9b9504dc26256c Return-path: Received: from eggs.gnu.org ([208.118.235.92]:52992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZnvL-000871-Ck for emacs-orgmode@gnu.org; Tue, 07 May 2013 15:51:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZnvH-0004Ho-3W for emacs-orgmode@gnu.org; Tue, 07 May 2013 15:51:43 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:61903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZnvG-0004HY-TH for emacs-orgmode@gnu.org; Tue, 07 May 2013 15:51:39 -0400 Received: by mail-pa0-f53.google.com with SMTP id kq12so751911pab.12 for ; Tue, 07 May 2013 12:51:37 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --e89a8f5037922b9b9504dc26256c Content-Type: multipart/alternative; boundary=e89a8f5037922b9b9204dc26256a --e89a8f5037922b9b9204dc26256a Content-Type: text/plain; charset=UTF-8 Hi fellow orgmoders, I am not sure this is a bug but in version 8.x storing a link using an external link type, org-store-link seems to call the external link type's store function twice... I noticed this as I use an external link type that asynchronous updates an external filedatabase and started to get random file lock errors -- the org-store-link second call to the external link type's store function sometimes came too quickly after the first one. :-) Also, I do not have this problem in version 7.x of orgmode. Instead of reverting back to a previous version of orgmode I started to investigate -- attaching a patch that seems to help me anyway. It's not that well tested and maybe, as I am not that familiar with everything going on when storing a link using an external link type, it will break other things... yours, /robert PS. I will not file a formal bug report as it might not be a bug, just me getting upset of a probable superfluous funcall... M-x version: GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4) of 2013-04-14 on marid, modified by Debian M-x org-version: Org-mode version 8.0.2 (8.0.2-10-g3e1d83-elpa @ /home/robert/.emacs.d/elpa/org-20130506/) --e89a8f5037922b9b9204dc26256a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi fellow orgmoders,

I am not sure this is a bug but in version 8.x = storing a link using an external link type, org-store-link seems to call th= e external link type's store function twice... I noticed this as I use = an external link type that asynchronous updates an external filedatabase an= d started to get random file lock errors -- the org-store-link second call = to the external link type's store function sometimes came too quickly a= fter the first one. :-) Also, I do not have this problem in version 7.x of = orgmode.

Instead of reverting back to a previous version of orgmode I started to= investigate -- attaching a patch that seems to help me anyway. It's no= t that well tested and maybe, as I am not that familiar with everything goi= ng on when storing a link using an external link type, it will break other = things...

yours,
/robert

PS. I will not file a formal bug report as it = might not be a bug, just me getting upset of a probable superfluous funcall...

M-x version:
GNU Emacs 24.= 3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4) of 2013-04-14 on marid, modif= ied by Debian
M-x org-version:
Org-mode version 8.0.2 (8.0.2-10-g3e1d83-elpa @ /home/r= obert/.emacs.d/elpa/org-20130506/)


--e89a8f5037922b9b9204dc26256a-- --e89a8f5037922b9b9504dc26256c Content-Type: application/octet-stream; name="org.el.patch" Content-Disposition: attachment; filename="org.el.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgfhst510 LS0tIG9yZy5lbAkyMDEzLTA1LTA3IDIxOjA0OjQyLjIzMDI2NTc2NiArMDIwMAorKysgb3JnLm5l dy5lbAkyMDEzLTA1LTA3IDIxOjA0OjExLjM3NDQ1OTk3OCArMDIwMApAQCAtOTM4OSwxMCArOTM4 OSw5IEBACiAJCQkJIChjb21wbGV0aW5nLXJlYWQKIAkJCQkgICJXaGljaCBmdW5jdGlvbiBmb3Ig Y3JlYXRpbmcgdGhlIGxpbms/ICIKIAkJCQkgIHNmdW5zbiB0IChjYXIgc2Z1bnNuKSkpKSkKLQkJ ICAoZnVuY2FsbCAoY2FhciBzZnVucykpKQogCSAgICAgIChzZXRxIGxpbmsgKHBsaXN0LWdldCBv cmctc3RvcmUtbGluay1wbGlzdCA6bGluaykKIAkJICAgIGRlc2MgKG9yIChwbGlzdC1nZXQgb3Jn LXN0b3JlLWxpbmstcGxpc3QKLQkJCQkJOmRlc2NyaXB0aW9uKSBsaW5rKSkpKQorCQkJCQk6ZGVz Y3JpcHRpb24pIGxpbmspKSkpKQogCiAJOzsgU3RvcmUgYSBsaW5rIGZyb20gYSBzb3VyY2UgY29k ZSBidWZmZXIKIAkoKG9yZy1zcmMtZWRpdC1idWZmZXItcCkK --e89a8f5037922b9b9504dc26256c--