* Programming with org-element-cache -> short introduction?
@ 2014-08-10 0:47 Thorsten Jolitz
2014-08-11 13:16 ` Nicolas Goaziou
0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Jolitz @ 2014-08-10 0:47 UTC (permalink / raw)
To: emacs-orgmode
Hi List (or rather Hi Nicolas),
when programming with Org elements sometimes things seem to work and
then something strange happens - what smells like a cache problem. I
don't mean a cache bug, but a programmer (me) not taking the cache
into account the right way.
Is there a short introduction somewhere about the 'todos' and 'nogos' in
programming with elements wrt to the org-element-cache?
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Programming with org-element-cache -> short introduction?
2014-08-10 0:47 Programming with org-element-cache -> short introduction? Thorsten Jolitz
@ 2014-08-11 13:16 ` Nicolas Goaziou
2014-08-11 13:50 ` Thorsten Jolitz
0 siblings, 1 reply; 4+ messages in thread
From: Nicolas Goaziou @ 2014-08-11 13:16 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Hello,
Thorsten Jolitz <tjolitz@gmail.com> writes:
> when programming with Org elements sometimes things seem to work and
> then something strange happens - what smells like a cache problem. I
> don't mean a cache bug, but a programmer (me) not taking the cache
> into account the right way.
It might also be a cache problem. Do not hesitate to report it.
> Is there a short introduction somewhere about the 'todos' and 'nogos' in
> programming with elements wrt to the org-element-cache?
The only "nogo" is to never modify (destructively) a value returned by
`org-element-at-point' or `org-element-context'. Consider their return
value as read-only, and possibly invalid as soon as you modify the
buffer.
These advices don't apply to `org-element-parse-buffer', which doesn't
use cache (if it did, it should copy cached elements beforehand anyway).
HTH,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Programming with org-element-cache -> short introduction?
2014-08-11 13:16 ` Nicolas Goaziou
@ 2014-08-11 13:50 ` Thorsten Jolitz
2014-08-11 14:22 ` Nicolas Goaziou
0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Jolitz @ 2014-08-11 13:50 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
Hello,
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> when programming with Org elements sometimes things seem to work and
>> then something strange happens - what smells like a cache problem. I
>> don't mean a cache bug, but a programmer (me) not taking the cache
>> into account the right way.
>
> It might also be a cache problem. Do not hesitate to report it.
Ok
>> Is there a short introduction somewhere about the 'todos' and 'nogos' in
>> programming with elements wrt to the org-element-cache?
>
> The only "nogo" is to never modify (destructively) a value returned by
> `org-element-at-point' or `org-element-context'. Consider their return
> value as read-only, and possibly invalid as soon as you modify the
> buffer.
This one directly applies to my use-case (wrt `org-element-at-point').
Is it ok to do these two things:
- let-bind a value returned by `org-element-at-point' and modify it (with
plist-put), and
1. then return the interpreted value or
2. do (delete-region ...) on old element and then insert the
(interpreted) new one?
- globally set a value returned by `org-element-at-point', modify it
(with plist-put) in a function call, but use the variable as a quoted
(!) function arg and reset the original value with this trick:
#+begin_src emacs-lisp
(setq X (org-element-at-point))
(defun foo (element &optional replace-p)
(let ((elem (eval element)))
[...destructively modify elem...]
[...interpret elem ...]
(when replace-p
[...delete old-element ...]
[...insert interpreted elem, goto beg ...]
(set element (org-element-at-point)))))
(foo 'X t)
#+end_src
> These advices don't apply to `org-element-parse-buffer', which doesn't
> use cache (if it did, it should copy cached elements beforehand anyway).
Ok
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Programming with org-element-cache -> short introduction?
2014-08-11 13:50 ` Thorsten Jolitz
@ 2014-08-11 14:22 ` Nicolas Goaziou
0 siblings, 0 replies; 4+ messages in thread
From: Nicolas Goaziou @ 2014-08-11 14:22 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Is it ok to do these two things:
>
> - let-bind a value returned by `org-element-at-point' and modify it (with
> plist-put), and
No, per advice given before. `plist-put' is destructive.
Instead, create a new element. You can use `org-combine-plists' to
generate its property list.
[...]
> - globally set a value returned by `org-element-at-point', modify it
> (with plist-put) in a function call, but use the variable as a quoted
> (!) function arg and reset the original value with this trick:
Ditto.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-08-11 14:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-10 0:47 Programming with org-element-cache -> short introduction? Thorsten Jolitz
2014-08-11 13:16 ` Nicolas Goaziou
2014-08-11 13:50 ` Thorsten Jolitz
2014-08-11 14:22 ` Nicolas Goaziou
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).