From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: Programming with org-element-cache -> short introduction? Date: Mon, 11 Aug 2014 15:50:42 +0200 Message-ID: <87fvh3m8y5.fsf@gmail.com> References: <87y4uxp3w2.fsf@gmail.com> <87iolzp3nf.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGq0H-0004I9-12 for emacs-orgmode@gnu.org; Mon, 11 Aug 2014 09:51:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGq0A-0004ml-Uh for emacs-orgmode@gnu.org; Mon, 11 Aug 2014 09:51:12 -0400 Received: from plane.gmane.org ([80.91.229.3]:33747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGq0A-0004mZ-PF for emacs-orgmode@gnu.org; Mon, 11 Aug 2014 09:51:06 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XGq07-0004DG-EN for emacs-orgmode@gnu.org; Mon, 11 Aug 2014 15:51:03 +0200 Received: from e178191224.adsl.alicedsl.de ([85.178.191.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2014 15:51:03 +0200 Received: from tjolitz by e178191224.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2014 15:51:03 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: Hello, > Thorsten Jolitz 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