From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: How to change a link?
Date: Thu, 16 Oct 2014 00:28:51 +0200 [thread overview]
Message-ID: <874mv5ynks.fsf@gmail.com> (raw)
In-Reply-To: 877g01joiw.fsf@wmi.amu.edu.pl
Marcin Borkowski <mbork@wmi.amu.edu.pl> 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
next prev parent reply other threads:[~2014-10-15 22:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 0:19 How to change a link? Marcin Borkowski
2014-10-15 7:16 ` Thorsten Jolitz
2014-10-15 9:50 ` Marcin Borkowski
2014-10-15 10:02 ` Thorsten Jolitz
2014-10-15 16:17 ` Marcin Borkowski
2014-10-15 22:28 ` Thorsten Jolitz [this message]
2014-10-15 22:36 ` Marcin Borkowski
2014-10-15 22:51 ` Thorsten Jolitz
2014-10-15 23:06 ` Thorsten Jolitz
2014-10-15 10:19 ` Nicolas Goaziou
2014-10-15 21:30 ` Marcin Borkowski
2014-10-15 21:52 ` Nicolas Goaziou
2014-10-16 17:55 ` Marcin Borkowski
2014-10-16 20:10 ` Nicolas Goaziou
2014-10-16 21:46 ` Marcin Borkowski
2014-10-16 22:19 ` Thorsten Jolitz
2014-10-17 8:52 ` Marcin Borkowski
2014-10-17 15:25 ` Nick Dokos
2014-10-18 13:54 ` Thorsten Jolitz
2014-10-18 1:44 ` Marcin Borkowski
2014-10-18 13:48 ` Thorsten Jolitz
2014-10-20 0:02 ` Marcin Borkowski
2014-10-20 13:02 ` Nicolas Goaziou
2014-10-20 13:11 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874mv5ynks.fsf@gmail.com \
--to=tjolitz@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).