From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew MacLean Subject: re-search-forward hang in org-link-search Date: Thu, 13 Aug 2015 12:00:27 -0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a113cee2a5d3d9a051d351dc0 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPwoA-00018H-1b for emacs-orgmode@gnu.org; Thu, 13 Aug 2015 14:00:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPwo3-0003JA-RJ for emacs-orgmode@gnu.org; Thu, 13 Aug 2015 14:00:53 -0400 Received: from mail-oi0-x22f.google.com ([2607:f8b0:4003:c06::22f]:35220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPwo3-0003IA-Fl for emacs-orgmode@gnu.org; Thu, 13 Aug 2015 14:00:47 -0400 Received: by oiew67 with SMTP id w67so12358637oie.2 for ; Thu, 13 Aug 2015 11:00:46 -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 --001a113cee2a5d3d9a051d351dc0 Content-Type: multipart/alternative; boundary=001a113cee2a5d3d93051d351dbe --001a113cee2a5d3d93051d351dbe Content-Type: text/plain; charset=UTF-8 So, I found a hang in org-link-search... (In what I think is an Emacs bug, but posting this here certainly can't hurt.) When you have a headline with a tag (For example "Mawile" with ":something:" as a tag), and another headline later in the buffer beginning with the other headline's title within a word boundary (For example "Mawile stuff", but not "Mawile's stuff"), if you try to create a link to the second headline, Emacs hangs. I've attached an Org file where, if you click the link, the buffer will freeze. I've narrowed down the problem to the "(re-search-forward re nil t)" form of the "Regular text search" section of org-link-search in org.el. The regular expression generated for me when I click that link is: ^\*+ \(?:\(BUG\|CANCELLED\|DONE\|FIXED\|KNOWNCAUSE\|REPORT\|TODO\)[ ]+\)?\(?:\[#.\][ ]+\)?\(?:COMMENT[ ]+\)?\(?:[ ]+\|\(?:[ ]*\[[0-9]*\(?:%\|/[0-9]*\)\][ ]*\)+\)*Mawile\(?:[ ]+\|\(?:[ ]*\[[0-9]*\(?:%\|/[0-9]*\)\][ ]*\)+\)+stuff\(?:[ ]+\|\(?:[ ]*\[[0-9]*\(?:%\|/[0-9]*\)\][ ]*\)+\)*\(?:[ ]+:[[:alnum:]_@#%%:]+:\)?[ ]*$ And indeed, in the buffer, if you have the point before the first headline and M-x re-search-forward the above regex, Emacs hangs. (However, if you have point after the headline, it finds the correct location fine.) In the org-link-search function, point is set to (point-min) before performing the re-search-forward, so the hang will occur regardless of where the link or headline is, as long as the tagged headline comes first. This happens with the latest Org mode code from the master branch on Emacs 24.5.1 (x86_64) on Linux Mint 17.2. I think this is an Emacs bug with re-search-forward since that function is a built-in C function and is hanging, though I figured I should give a heads up here first. (To either verify my findings in case I missed something and check it on other Emacs versions, or to find a defensive workaround.) This is just speculation, but I think it might be caused by how re-search-forward is reacting to the tag of the first heading because it is wrapped in ":" characters. --001a113cee2a5d3d93051d351dbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, I found a hang in org-link-search... (In what I think = is an Emacs bug, but posting this here certainly can't hurt.)

Wh= en you have a headline with a tag (For example "Mawile" with &quo= t;:something:" as a tag), and another headline later in the buffer beg= inning with the other headline's title within a word boundary (For exam= ple "Mawile stuff", but not "Mawile's stuff"), if y= ou try to create a link to the second headline, Emacs hangs.

I'v= e attached an Org file where, if you click the link, the buffer will freeze= .

I've narrowed down the problem to the "(re-search-forward= re nil t)" form of the "Regular text search" section of org= -link-search in org.el.

The regular expression generated for me when= I click that link is:

=C2=A0 ^\*+ \(?:\(BUG\|CANCELLED\|DONE\|FIXED= \|KNOWNCAUSE\|REPORT\|TODO\)[ ]+\)?\(?:\[#.\][ ]+\)?\(?:COMMENT[ ]+\)?\(?:[= ]+\|\(?:[ ]*\[[0-9]*\(?:%\|/[0-9]*\)\][ ]*\)+\)*Mawile\(?:[ ]+\|\(?:[ ]*\[= [0-9]*\(?:%\|/[0-9]*\)\][ ]*\)+\)+stuff\(?:[ ]+\|\(?:[ ]*\[[0-9]*\(?:%\|/[0= -9]*\)\][ ]*\)+\)*\(?:[ ]+:[[:alnum:]_@#%%:]+:\)?[ ]*$

And indeed, i= n the buffer, if you have the point before the first headline and M-x re-se= arch-forward the above regex, Emacs hangs. (However, if you have point afte= r the headline, it finds the correct location fine.)

In the org-link= -search function, point is set to (point-min) before performing the re-sear= ch-forward, so the hang will occur regardless of where the link or headline= is, as long as the tagged headline comes first.

This happens with t= he latest Org mode code from the master branch on Emacs 24.5.1 (x86_64) on = Linux Mint 17.2.

I think this is an Emacs bug with re-search-forward= since that function is a built-in C function and is hanging, though I figu= red I should give a heads up here first. (To either verify my findings in c= ase I missed something and check it on other Emacs versions, or to find a d= efensive workaround.)

This is just speculation, but I think it might= be caused by how re-search-forward is reacting to the tag of the first hea= ding because it is wrapped in ":" characters.

--001a113cee2a5d3d93051d351dbe-- --001a113cee2a5d3d9a051d351dc0 Content-Type: application/octet-stream; name="hang.org" Content-Disposition: attachment; filename="hang.org" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idai13ye0 W1tNYXdpbGUgc3R1ZmZdXQoqIE1hd2lsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA6c29tZXRoaW5nOgoqIE1hd2lsZSBzdHVmZgo= --001a113cee2a5d3d9a051d351dc0--