export to html stuck in loop scanning for org IDs

export to html stuck in loop scanning for org IDs

[Bruce Gilstrap]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Hello,

Until today, I had been running org-mode version 8.2.10 in GNU Emacs 24.3.1
on Windows 7 Ultimate (Service Pack 1). In an attempt to work around a
problem with this version of org-mode, I updated org-mode to the latest
daily snapshot (version 8.3beta). This fixed my previous problem but
introduced another.

When I attempt to export to HTML, the process gets stuck in a loop scanning
for IDs. The entry in the *Message* buffer reads "680 unique files scanned
for IDs [2 times]" where the number of times varies with how long I let it
run before pressing C-g.

This happens consistently with one file that I successfully exported last
Friday under 8.2.10 but does not happen at all with some other files. So
far, I have been unable to isolate exactly what it is about this file that
causes the export to get stuck in this loop. I can do the legwork to track
it down if someone more knowledgeable about the exporter can point me in
the right direction. It seems obvious that it has something to do with IDs,
but the files that still export properly contain IDs, too, so the issue
isn't as simple as the existence of IDs in the file.

Here are the last few lines in the *Messages* buffer, in case they might be
helpful:

org-babel-exp process R at line 5400...
executing R code block...
Code block evaluation complete.
org-babel-exp process html at line 7062...
680 unique files scanned for IDs [2 times]
Quit

Thanks,
Bruce

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: export to html stuck in loop scanning for org IDs

[Rasmus]

Hi Bruce,

Bruce Gilstrap <bruce@gilstraps.org> writes:

> This happens consistently with one file that I successfully exported last
> Friday under 8.2.10 but does not happen at all with some other files. So
> far, I have been unable to isolate exactly what it is about this file that
> causes the export to get stuck in this loop. I can do the legwork to track
> it down if someone more knowledgeable about the exporter can point me in
> the right direction. It seems obvious that it has something to do with IDs,
> but the files that still export properly contain IDs, too, so the issue
> isn't as simple as the existence of IDs in the file.

Would it be possible to bisect your file to find the offending part?
Otherwise you could try to hot-patch org-id-update-id-locations in
org-id.el.  For instance, try to change the last (if ...) to:

(if (> ndup 0)
	  (message "WARNING: %d duplicate IDs found, check *Messages* buffer" ndup)
	(progn (message "%d unique files scanned for IDs" (length org-id-files))
	       (message (mapconcat (lambda (x) (format "%s" x)) org-id-files "\n"))))

To see which files it is scanning.  Maybe that will give a clue as to
where the problem is.

Do you use #+INCLUDE?

Rasmus

-- 
Er du tosset for noge' lårt!

Re: export to html stuck in loop scanning for org IDs

[Bruce Gilstrap]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

Rasmus,

I had started down the path of bisecting the file, but wasn't having much
luck isolating the problem, so I posted the question. I had some time to
get back to it this afternoon, and I eventually tracked this down. It had
to do with a missing ID rather than a duplicate one. The file contained a
link to an ID that no longer existed in the file (or in any other org
files), but it wasn't listed in the *Messages* buffer and export kept
searching through all my org files over and over until I pressed C-g. When
I removed that link, I still had some other problems in the file with text
links, i.e. [[target]], that didn't have a matching target, i.e.,
<<target>>, but now these were identified in the *Messages* buffer (one per
export attempt until I found them all). Once all of those were fixed, the
export ran successfully.

I do use #+INCLUDE, but that is not the problem here.

Thanks,
Bruce


On Fri, Jul 24, 2015 at 4:38 AM, Rasmus <rasmus@gmx.us> wrote:

> Hi Bruce,
>
> Bruce Gilstrap <bruce@gilstraps.org> writes:
>
> > This happens consistently with one file that I successfully exported last
> > Friday under 8.2.10 but does not happen at all with some other files. So
> > far, I have been unable to isolate exactly what it is about this file
> that
> > causes the export to get stuck in this loop. I can do the legwork to
> track
> > it down if someone more knowledgeable about the exporter can point me in
> > the right direction. It seems obvious that it has something to do with
> IDs,
> > but the files that still export properly contain IDs, too, so the issue
> > isn't as simple as the existence of IDs in the file.
>
> Would it be possible to bisect your file to find the offending part?
> Otherwise you could try to hot-patch org-id-update-id-locations in
> org-id.el.  For instance, try to change the last (if ...) to:
>
> (if (> ndup 0)
>           (message "WARNING: %d duplicate IDs found, check *Messages*
> buffer" ndup)
>         (progn (message "%d unique files scanned for IDs" (length
> org-id-files))
>                (message (mapconcat (lambda (x) (format "%s" x))
> org-id-files "\n"))))
>
> To see which files it is scanning.  Maybe that will give a clue as to
> where the problem is.
>
> Do you use #+INCLUDE?
>
> Rasmus
>
> --
> Er du tosset for noge' lårt!
>
>
>

[-- Attachment #2: Type: text/html, Size: 3090 bytes --]

Re: export to html stuck in loop scanning for org IDs

[Rasmus]

Hi Bruce,

Thank you for looking into this!

Bruce Gilstrap <bruce@gilstraps.org> writes:

> I had started down the path of bisecting the file, but wasn't having much
> luck isolating the problem, so I posted the question. I had some time to
> get back to it this afternoon, and I eventually tracked this down. It had
> to do with a missing ID rather than a duplicate one. The file contained a
> link to an ID that no longer existed in the file (or in any other org
> files), but it wasn't listed in the *Messages* buffer and export kept
> searching through all my org files over and over until I pressed C-g. When
> I removed that link, I still had some other problems in the file with text
> links, i.e. [[target]], that didn't have a matching target, i.e.,
> <<target>>, but now these were identified in the *Messages* buffer (one per
> export attempt until I found them all). Once all of those were fixed, the
> export ran successfully.

This sounds nasty.  Would you be able to produce some minimal examples
that trigger this behavior?

Also, do you see the problems when starting a plain Emacs (emacs -q or
emacs -Q depending on your setup).

> I do use #+INCLUDE, but that is not the problem here.

INCLUDE is a lot more powerful in Org 8.3 than 8.2.  I though I'd perhaps
introduced new, unknown recursion bugs.  But now we know it is unrelated.

Thanks,
Rasmus

-- 
May contains speling mistake