Hi, This used to work, back in August but I just updated today and Something Has Changed. After setting this option: (setq org-link-abbrev-alist '(("att" . org-attach-expand-link))) 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). Inspecting the output shows that the link is wrong: /home/myles/myorg/FigureA.jpg When it should be: /home/myles/myorg/data/ad/c7f168-33bb-4e38-83fa-6aea6708563b/FigureA.jpg Can anyone tell me how to get the link exported correctly? (And why has the indenting of this email gone weird?) Thanks, Myles
Hi,
· Myles English <mylesenglish@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.goaziou@gmail.com>
Date: Fri Aug 30 13:29:51 2013 +0200
org-element: Fix parsing error in `org-element-context'
* lisp/org-element.el (org-element-text-markup-successor,
org-element-latex-or-entity-successor,
org-element-export-snippet-successor,
org-element-footnote-reference-successor,
org-element-inline-babel-call-successor,
org-element-inline-src-block-successor,
org-element-line-break-successor, org-element-link-successor,
org-element-plain-link-successor, org-element-macro-successor,
org-element-radio-target-successor,
org-element-statistics-cookie-successor,
org-element-sub/superscript-successor,
org-element-table-cell-successor, org-element-target-successor,
org-element-timestamp-successor): Remove LIMIT argument.
(org-element--parse-objects, org-element--get-next-object-candidates):
Apply signature change to successors.
(org-element-context): Narrow buffer around object containers so
parsing of objects when using this function is done under the same
restrictions as in buffer parsing.
* testing/lisp/test-org-element.el: Add test.
introduced the bug. Now my elisp knowledge is too weak to debug this
further, but hopefully this helps to trace down the root cause.
Thanks a lot for org. I really don't know how to survive without it :-)
--
Bis neulich ...
Thomas
Hello,
Thomas Holst <thomas.holst@de.bosch.com> writes:
> · Myles English <mylesenglish@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.goaziou@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.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> Thomas Holst <thomas.holst@de.bosch.com> writes:
>
>> · Myles English <mylesenglish@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.goaziou@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
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 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.
Done for `org-entry-properties'. The regression should be fixed now.
Thank you for the report.
Regards,
--
Nicolas Goaziou
Hi,
· Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> 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.
>
> Done for `org-entry-properties'. The regression should be fixed now.
>
> Thank you for the report.
Thanks for fixing it! I don't have time to test it today. But I will do
so tomorrow. I will report.
--
Bis neulich ...
Thomas
Nicolas,
> · Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>>
>> Done for `org-entry-properties'. The regression should be fixed now.
>>
>> Thank you for the report.
Thanks very much, I'll test it soon.
Myles
Hi Nicolas,
· Thomas Holst <thomas.holst@de.bosch.com> wrote:
> Hi,
>
> · Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>>> 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.
>>
>> Done for `org-entry-properties'. The regression should be fixed now.
>>
>> Thank you for the report.
>
> Thanks for fixing it! I don't have time to test it today. But I will do
> so tomorrow. I will report.
sorry for the late answer. I could only test it today.
For me the problem still persists.
Here is my way to produce it.
- start emacs (Win7)
: start C:\Programme\gnu\emacs-24.3\bin\emacs.exe -Q --eval "(load-file \"testing.el\")"
- testing.el
#+begin_src emacs_lisp
(add-to-list 'load-path "~/git/org-mode/lisp")
(add-to-list 'load-path "~/git/site-lisp")
;; pfad zu contib/lisp
(add-to-list 'load-path "~/git/org-mode/contrib/lisp")
(add-to-list 'load-path "~/git/org-mode/contrib/babel/lisp")
(require 'org-install)
(require 'ox)
(require 'ox-latex)
(require 'org-attach)
(setq org-link-abbrev-alist '(("att" . org-attach-expand-link)))
(find-file "testing.org")
#+end_src
- testing.org
#+begin_src org
#+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:{} -:t f:t *:t <:t
#+OPTIONS: TeX:dvipng LaTeX:t skip:nil d:t todo:t pri:nil tags:nil
* Attachment :ATTACH:
:PROPERTIES:
:Attachments: overview.png
:ID: 1eb9cb02-4011-4720-932b-2934e99827d0
:END:
With org-version:
#+BEGIN_SRC emacs-lisp :exports results
(org-version nil t)
#+END_SRC
#+RESULTS:
: Org-mode version 8.0.7 (release_8.0.7 @ path-to/org-mode/lisp/)
an attachment link
#+BEGIN_VERBATIM
att:overview.png
#+END_VERBATIM
gets exported as:
[[att:overview.png]]
#+end_src
The link gets exportet as:
Org-mode version 8.0.7 (release_8.0.7 @ path-to/org-mode/lisp/)
[file:c:/temp/att-links/data/1e/b9cb02-4011-4720-932b-2934e99827d0/overview.png]
Org-mode version 8.2.3c (release_8.2.3c-251-gbb97f5 @ path-to/git/org-mode/lisp/)
[file:c:/temp/att-links/overview.png]
So obviously the sub path to the attachment is missing in the link
Thanks for looking into this.
--
Bis neulich ...
Thomas
Hello,
Thomas Holst <thomas.holst@de.bosch.com> writes:
> For me the problem still persists.
Thank you for the report.
I pushed another fix. Please let me know if it doesn't do its job.
Regards,
--
Nicolas Goaziou
Hi Nicolas, · Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Thomas Holst <thomas.holst@de.bosch.com> writes: >> For me the problem still persists. > Thank you for the report. > I pushed another fix. Please let me know if it doesn't do its job. Works like a charm again. Thanks for fix. -- Bis neulich ... Thomas