Re: [O] export to html stuck in loop scanning for org IDs
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 ras...@gmx.us wrote: Hi Bruce, Bruce Gilstrap br...@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!
[O] export to html stuck in loop scanning for org IDs
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
Re: [O] PROPERTIES drawer inserted within LOGBOOK drawer during org-capture
Indeed, I cannot reproduce the problem in the most recent daily snapshot (org-version = 8.3beta). Thanks, Bruce On Mon, Jul 20, 2015 at 4:07 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Bruce Gilstrap br...@gilstraps.org writes: I am running org-mode version 8.2.10 in GNU Emacs 24.3.1 on Windows 7 Ultimate (Service Pack 1). When I invoke org-capture while the cursor is on or under a TODO headline that does not have a PROPERTIES drawer, org inserts a PROPERTIES drawer and an ID key-value pair, like so: Could you update Org to development version and try it again? This might be fixed already. Regards, -- Nicolas Goaziou
[O] PROPERTIES drawer inserted within LOGBOOK drawer during org-capture
Hello, I am running org-mode version 8.2.10 in GNU Emacs 24.3.1 on Windows 7 Ultimate (Service Pack 1). When I invoke org-capture while the cursor is on or under a TODO headline that does not have a PROPERTIES drawer, org inserts a PROPERTIES drawer and an ID key-value pair, like so: * TODO New headline :PROPERTIES: :ID: b0ee991b-cccb-46cc-8f43-a2341de68e4d :END: When the LOGBOOK contains a note after a clock entry, however, org inserts the PROPERTIES drawer inside the existing LOGBOOK drawer, like so: * TODO The LOGBOOK contains one complete clock entry and note after clock entry :LOGBOOK: CLOCK: [2015-07-20 Mon 08:56]--[2015-07-20 Mon 09:03] = 0:07 :PROPERTIES: :ID: e1cefdae-a34d-4ba1-bb80-7f05cd541605 :END: - Note taken on [2015-07-20 Mon 13:16] \\ a note :END: This behavior does not happen when: * TODO There is no LOGBOOK drawer :PROPERTIES: :ID: ebb1a5f2-0546-48aa-b18b-6d00fde03fcf :END: * TODO The LOGBOOK is empty :LOGBOOK: :END: :PROPERTIES: :ID: c51f2f0a-0fe2-4182-9bc1-72ed5085070f :END: * TODO The LOGBOOK contains only note :LOGBOOK: - Note taken on [2015-07-20 Mon 13:13] \\ a note :END: :PROPERTIES: :ID: 5954a100-1da5-47f0-a73c-456b29024590 :END: * TODO The LOGBOOK note precedes a clock entry :LOGBOOK: - Note taken on [2015-07-20 Mon 13:14] \\ a note CLOCK: [2015-07-20 Mon 08:56]--[2015-07-20 Mon 09:03] = 0:07 :END: :PROPERTIES: :ID: d8682ba6-5233-4c94-b2bc-2a90c287f980 :END: * TODO The LOGBOOK contains a note between two clock entries :LOGBOOK: CLOCK: [2015-07-20 Mon 13:30]--[2015-07-20 Mon 13:42] = 0:12 - Note taken on [2015-07-20 Mon 13:22] \\ a note CLOCK: [2015-07-20 Mon 08:56]--[2015-07-20 Mon 09:03] = 0:07 :END: :PROPERTIES: :ID: 4c3b7ef5-5d0a-4de5-965c-2b8d46524931 :END: Has anyone seen this behavior before? Thanks, Bruce
[O] Unexpected link behavior after exporting Org-mode file to HTML
Hello, I am running Org-mode 8.2.7c in Emacs 24.3.1 on Windows 7 Ultimate and have encountered a peculiarity with how links work in HTML exported from Org-mode. I searched gmane.emacs.orgmode to see if someone else has reported this before, but I didn't find anything exactly like this. Please pardon me if I have missed something. I have used org-id extensively to assign unique IDs to headings in Org-mode files (stored in the :PROPERTIES: drawer of the heading). Before the new exporter framework was introduced in Org-mode 8.0 all of these links worked without issue: no matter the level of the heading's hierarchy, exported-HTML ID-based links worked fine. However, using the new exporter framework produces different results. Now, ID-based links always fail when the target heading lies at a level below the headline level defined in the export settings, which defaults to level 3 (H:3). Note: This is true only for the exported HTML; ID-based links work perfectly within Emacs. Here is a minimal example that demonstrates this behavior when I export it to HTML (see annotations for details): #+OPTIONS: toc:nil * Headline Level 1 ** Headline Level 2 *** Headline Level 3 :PROPERTIES: :ID: 307db49e-e001-4a7b-9541-96eee2ae6f06 :END: heading-level-4Non-headline level :PROPERTIES: :ID: 3be9179d-f838-4052-93ca-6c76c9aff12d :END: * Headline Level 1 Now I want to link to information that appears elsewhere in the file. Links work as expected within Emacs. When exported to HTML, however, links do not work as they did before the new exporter framework was introduced in Org-mode 8.0. [[id:307db49e-e001-4a7b-9541-96eee2ae6f06][ID-based link to 1.1.1]] This link /does/ work. Using IDs always works for links to any headline level. By headline level I mean any Org-mode heading that is defined as a headline (default H:3). [[id:3be9179d-f838-4052-93ca-6c76c9aff12d][ID-based link to Non-headline level]] This link using the ID /doesn't/ work when exported to HTML using the new exporter framework. Now, using IDs as the target for links /always/ fails for links to any headline lower than the headline level defined in the export settings. [[heading-level-4][Non-ID-based link to Non-headline level]] Using an internal link works, but I have /many/ existing files that depend on IDs for links at heading levels lower than the levels I want treated as (numbered) headlines. You can view the exported HTML file here: http://work.gilstraps.org/org/demo-links.html I believe the relevant function in ox-html.el is org-html-headline, but I'm a novice (at best) with elisp. My questions are these: 1. Is this behavior by design? 2. If so, how can I make ID-based links to non-headlines work the way I expect them to? 3. If not, shouldn't this be treated as a bug? Thanks, Bruce
Re: [O] Unexpected link behavior after exporting Org-mode file to HTML
Thank you for fixing it. I have tested it and it works as expected now. Bruce On Thu, Sep 18, 2014 at 3:11 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hello, Bruce Gilstrap br...@gilstraps.org writes: I am running Org-mode 8.2.7c in Emacs 24.3.1 on Windows 7 Ultimate and have encountered a peculiarity with how links work in HTML exported from Org-mode. I searched gmane.emacs.orgmode to see if someone else has reported this before, but I didn't find anything exactly like this. Please pardon me if I have missed something. I have used org-id extensively to assign unique IDs to headings in Org-mode files (stored in the :PROPERTIES: drawer of the heading). Before the new exporter framework was introduced in Org-mode 8.0 all of these links worked without issue: no matter the level of the heading's hierarchy, exported-HTML ID-based links worked fine. However, using the new exporter framework produces different results. Now, ID-based links always fail when the target heading lies at a level below the headline level defined in the export settings, which defaults to level 3 (H:3). Note: This is true only for the exported HTML; ID-based links work perfectly within Emacs. This should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
