Re: [O] How to change a link?

[Thorsten Jolitz]

Marcin Borkowski <address@hidden> writes:

> I see.  What is the most interesting for me is the idea of
> getting/setting properties, that's what I was looking for.

Thats exactly what org-dp (https://github.com/tj64/org-dp) is about: 
getting and setting element properties instead of working on the textual
representation in the buffer. 

Here the commentary section of org-dp.el:

,----
| ** Commentary
| 
| Functions for declarative local programming with Org elements. They
| allow to declare what should be done and leave the low-level work,
| the "how-to", to the Org parser/interpreter framework.
| 
| With other words, org-dp acts on the internal representation of Org
| elements rather than on their textual representation, and leaves
| the transformation between both representations to the
| parser/interpreter framework. To create or modify an element, you
| call the parser to open it up, rewire its internals, and then call
| the interpreter to build the element again based on its modified
| internals.
| 
| Since all Org elements are uniformely represented as nested lists
| internally, with their properties stored as key-val pairs in
| plists, they can be treated in a much more uniform way when dealing
| with the internal representation instead of the highly variable
| textual representations. A big advantage of plists is that only
| those properties that are actually accessed matter, so when
| transforming one Org element into another on the internal level one
| does not have to worry about not matching properties as long as
| these are not used by the interpreter when building the textual
| representation of the transformed element.
| 
| Library org-dp is meant for programming at the local level,
| i.e. without any (contextual) information except those about the
| parsed element at point. It is designed to make using the Org-mode
| parser/interpreter framework at local level as convenient as using
| it at the global level (with a complete parse-tree produced by
| `org-element-parse-buffer` available). It takes care of the
| org-element caching mechanism in that it only acts on copies of the
| locally parsed elements at point, never on the original parsed (and
| cached) object itself.
`----

With just a few functions:

,----
| (defun* org-dp-create (elem-type &optional contents insert-p
|                            affiliated &rest args)
| 
| (defun* org-dp-rewire (elem-type &optional contents replace
|                            affiliated element &rest args)
| 
| (defun org-dp-map (fun-with-args rgxp &optional match-pos
|                    backward-search-p beg end silent-p)
| 
| (defun org-dp-contents (&optional element interpret-p no-properties-p)
| 
| (defun* org-dp-prompt (&optional elem elem-lst &key noprompt- [...]
`----

you can do almost all you local Org programming (i.e. doing stuff
"at-point" without the need for a complete parse-tree) by getting and
setting element properties, thats why I called the library

,----
| org-dp.el --- Declarative Local Programming with Org Elements
`----

it allows to leave most of the low-level parsing and interpreting stuff
to the parser framework, you only need to 'declare' the element-type and
the property values to create or modify elements.

-- 
cheers,
Thorsten