Marcin Borkowski <mb...@wmi.amu.edu.pl> writes:
> On 2014-10-17, at 00:19, Thorsten Jolitz wrote:
>
>> However, here is a org-dp solution, use 't' instead of 'prepend to
>> replace the links, and whatever you want instead of "file+emacs" as
>> replacement. Of course one could easily re-search and replace "[[file:"
>> in this simple case, but this uses the parser and allows doing more
>> complex stuff in a clean way too:
>>
>> ,----
>> | #+BEGIN_SRC emacs-lisp :results none
>> | (require 'org-dp)
>> | (org-dp-map
>> | '(org-dp-rewire
>> | 'paragraph
>> | (lambda (cont elem)
>> | (let* ((link (car cont))
>> | (raw-val (org-element-property :raw-link link))
>> | (new-val (mapconcat 'identity
>> | (cons "file+emacs"
>> | (cdr
>> | (split-string
>> | raw-val ":" t)))
>> | ":")))
>> | (org-element-put-property link :raw-link new-val)))
>> | 'prepend)
>> | org-link-re-with-space t)
>> | #+END_SRC
>> `----
>
Hi Marcin,
> one thing I don't quite understand yet: why is the first argument to
> org-dp-rewire `'paragraph'? My intuition says it should rather be
> 'link, though this doesn't seem to work. How come that you say
> 'paragraph, but the lambda in the second parameter gets the link data in
> `cont'? (This might be a stupid question, but I really want to grok
> this.)
I was surprised too! But links are objects, and with point at a link
org-element-at-point return a paragraph with the link as content. So
to get the contents of a link, you take the contents of the contents
of a paragraph, but that a special case, because mostly you will work
directly with elements.
The 'paragraph' is the target element type. In this case I could have
written
,----
| '(org-dp-rewire nil ...)
`----
instead, since then parsed and rewired element types are the same. See
examples below of how to convert a link into a src-block or a keyword
(e.g.).
For more in depth info, have a look at:
,----[ C-h f org-dp-rewire RET ]
| org-dp-rewire is a Lisp function in `org-dp.el'.
|
| (org-dp-rewire ELEM-TYPE &optional CONTENTS REPLACE AFFILIATED ELEMENT
| &rest ARGS)
|
| Rewire element-at-point or ELEMENT (if given). [...]
`----
Example:
When you start with the file link below and eval the
following src-blocks in order, you get:
#+BEGIN_SRC picolisp
(println "Link label: min.org")
(println "Link type: file")
#+END_SRC
#+LABEL: min.org
[[file:junk/org/minimal.org][min.org]]
#+BEGIN_SRC emacs-lisp :results none
(require 'org-dp)
(org-dp-map
'(org-dp-rewire 'src-block nil 'prepend nil nil
:language "picolisp"
:value (lambda (_old_ elem)
(format
(concat
"(println \"Link label: %s\")\n"
"(println \"Link type: %s\")")
(org-dp-contents
(car (org-dp-contents elem nil t))
t t)
(org-element-property
:type (car
(org-dp-contents elem nil t))))))
org-link-re-with-space t)
#+END_SRC
#+BEGIN_SRC emacs-lisp :results none
(require 'org-dp)
(org-dp-map
'(org-dp-rewire 'keyword nil 'prepend nil nil
:key "LABEL"
:value (lambda (_old_ elem)
(org-dp-contents
(car (org-dp-contents elem nil t))
t t)))
org-link-re-with-space t)
#+END_SRC
This should give you a better idea of what the org-dp-rewire function
arguments stand for. In generel, org-dp functions have extensive
docstrings, so C-h f 'org-dp-xyz' is you friend.
For org-dp, the (few) properties that are interpreted are most
relevant, not so much the (many) properties that are parsed. See
variable `org-dp-elem-props' for an overview. In general, when
programming with org-dp, I often look into org-element.el, especially
at the interpreters.
> Second question: do I get it correctly that `org-element-put-property'
> returns the "new" version of the element (link, in this case), with
> everything as it was but the :raw-link property changed?
,----[ C-h f org-element-put-property RET ]
| org-element-put-property is a compiled Lisp function in
| `org-element.el'. [...]
| Return modified element.
`----
Yes!
--
cheers,
Thorsten
