From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Gilstrap Subject: Re: export to html stuck in loop scanning for org IDs Date: Fri, 24 Jul 2015 15:07:01 -0500 Message-ID: References: <87380dlwu6.fsf@gmx.us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f83973909ecdf051ba48c63 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIjFK-0007ya-Ln for emacs-orgmode@gnu.org; Fri, 24 Jul 2015 16:07:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZIjFH-0004WM-1I for emacs-orgmode@gnu.org; Fri, 24 Jul 2015 16:07:06 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:36906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIjFG-0004UX-Ov for emacs-orgmode@gnu.org; Fri, 24 Jul 2015 16:07:02 -0400 Received: by wibud3 with SMTP id ud3so41266844wib.0 for ; Fri, 24 Jul 2015 13:07:01 -0700 (PDT) In-Reply-To: <87380dlwu6.fsf@gmx.us> 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 --e89a8f83973909ecdf051ba48c63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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., <>, 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 wrote: > Hi Bruce, > > Bruce Gilstrap writes: > > > This happens consistently with one file that I successfully exported la= st > > Friday under 8.2.10 but does not happen at all with some other files. S= o > > 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 i= n > > 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=C3=A5rt! > > > --e89a8f83973909ecdf051ba48c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 exi= sted in the file (or in any other org files), but it wasn't listed in t= he *Messages* buffer and export kept searching through all my org files ove= r 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=C2=A0(one per export attempt until I fo= und them all). Once all of those were fixed, the export ran successfully.

I do use #+INCLUDE, but that is not the problem her= e.

Thanks,
Bruce


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

Bruce Gilstrap <bruce@gilstraps.o= rg> writes:

> This happens consistently with one file that I successfully exported l= ast
> 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 t= rack
> 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 issu= e
> 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.=C2=A0 For instance, try to change the last (if ...) to:

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

To see which files it is scanning.=C2=A0 Maybe that will give a clue as to<= br> where the problem is.

Do you use #+INCLUDE?

Rasmus

--
Er du tosset for noge' l=C3=A5rt!



--e89a8f83973909ecdf051ba48c63--