emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Links Lost and Export-Report


From: Stefan Vollmar
Subject: [Orgmode] Links Lost and Export-Report
Date: Wed, 18 Aug 2010 14:42:11 +0200

Hello,

I currently have a "showstopper-class" problem with links. I am using Org-mode 
release_7.01h-129-g3363a with Emacs 23.2.1. I have 

(require 'org-install)
(require 'org-id)

in my .emacs file.

This works fine:

(1) org-link-to-org-use-id is t and when I do a C-c l (org-store-link), a "a 
globally unique ID property" is generated for the current section - so far so 
good.
(2) I then change to another org-file and insert the link with C-c C-l 
(org-store-link), looking at the org source shows me that, indeed, the newly 
generated ID ("id:3A50..." in that example) has been used.
(3) When I do a C-c C-o (org-open-at-point) on the new link, the target 
org-file is opened at exactly the right place - nice!
(4) When I export the file as HTML, the link works exactly as expected: "<a 
href="some-file.html#ID-3A50...">

Here is the problem: I have two computers with very similar setups (Emacs and 
Org-mode: same versions; laptop and desktop) and synchronize org-files via a 
subversion repository. If I do a subversion update (sync the org-files to that 
computer) and then export to HTML on that computer, the previously working 
links do not work any more: there is no "#ID-..." in the link, in fact, the 
link is simply to the file that contains the link (not even the file I want to 
link to). Maybe Org-mode was not able to find the "id"?

I notice that there is no file referenced in the automatically generated 
"[[id:3A50...][My Link]]" link. How does Org-mode look for files that might 
contain a specific id? The org manual says "[...] and one that is globally 
unique and works even if the entry is moved from file to file" implying that 
there is a strategy for looking for suitable candidates. I assume that Org-mode 
will look in currently open buffers first, but even if I load the correct 
target file, HTML export will not create the proper link. Perhaps a caching 
problem (I use "global-auto-revert-mode")?

Maybe the above is a problem with my particular setup, but another and related 
problem is this:

Org-mode silently ignoring link problems and misspelled macro names is 
dangerous - it happened more than once in our case that HTML content went 
online with broken links and "{{{my-misspelled-macro()}}}" snippets. How about 
an (optional) report after generating more complex HTML contents: maybe it 
could be another org-file with links to offending Org code (unresolved links, 
unknown macro names) and an easy-to-parse summary line for batch jobs ("done in 
5.6s, *** 2 errors found")? I am perfectly willing to help with this, 
unfortunately, my elisp skills are fairly basic and I fear this requires some 
intimate knowledge of the export process. 

Many thanks in advance.
Warm regards,
 Stefan
-- 
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleuelerstr. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213  FAX +49-221-4726-298
Tel.: +49-221-478-5713  Mobile: 0160-93874279
Email: address@hidden   http://www.nf.mpg.de






Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]