Nicolas Goaziou <n.goaz...@gmail.com> writes: > Hello, > > Thomas Holst <thomas.ho...@de.bosch.com> writes: > >> ยท Myles English <mylesengl...@gmail.com> wrote: >> >> [ ... snip ... ] >>> It was possible to insert a link to an attachment like this: >>> >>> [[att:FigureA.jpg]] >>> >>> and clicking on it would show the file (still works), and it would show >>> up in the exported document (no longer happens). >> [ ... snip ... ] >> >> since I like this feature I'd like to give this thread a bump. With git >> bisecting I found that commit: >> >> 026b99ecb86e08f4fdc7b45ee2bfa1d4c84a37f6 is the first bad commit >> commit 026b99ecb86e08f4fdc7b45ee2bfa1d4c84a37f6 >> Author: Nicolas Goaziou <n.goaz...@gmail.com> >> Date: Fri Aug 30 13:29:51 2013 +0200 > > Since I have been proven guilty, let me add it to my TODO list.
Actually, this could solved by widening the buffer before expanding the link in `org-element-link-parser'. Though, I'm surprised that neither `org-id-get', `org-entry-get' nor, at the most basic level, `org-entry-properties' remove narrowing before computing their return value. Is there any reason for this? AFAICT, it would be better to wrap them with a `org-with-wide-buffer' macro. Cc'ing Carsten before patching blindly. Regards, -- Nicolas Goaziou
