From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [RFC] Rewrite `org-entry-properties' using parser Date: Fri, 01 Aug 2014 14:44:22 +0200 Message-ID: <87k36sl6qh.fsf@gmail.com> References: <87tx5xunas.fsf@gmail.com> <87ha1wcu49.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XDCCb-0007Ob-Kb for emacs-orgmode@gnu.org; Fri, 01 Aug 2014 08:44:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XDCCV-0007Ei-Nl for emacs-orgmode@gnu.org; Fri, 01 Aug 2014 08:44:53 -0400 Received: from plane.gmane.org ([80.91.229.3]:33129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XDCCV-0007CQ-HO for emacs-orgmode@gnu.org; Fri, 01 Aug 2014 08:44:47 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XDCCJ-0002rw-Hx for emacs-orgmode@gnu.org; Fri, 01 Aug 2014 14:44:35 +0200 Received: from e178189011.adsl.alicedsl.de ([85.178.189.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2014 14:44:35 +0200 Received: from tjolitz by e178189011.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2014 14:44:35 +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 Bastien writes: Hi Bastien, > Thorsten Jolitz writes: > >> here is my first take of rewriting `org-entry-properties'. > > I didn't take the time to closely look at the change, but thanks > for working on this. > > My main concern with anything that touches `org-entry-properties' > is whether agenda generation is affected in terms of performances. > Any change here needs to check this very carefully, because we > cannot affort to exchange speed against clarity (sadly enough.) I would guess it all depends on the speed of `org-element-at-point' then. I can test this with very big org files later, but first I would it to converge a bit towards a possibly acceptable version. E.g. when looking at the ERT tests it seems ugly and not helpfull that values of properties like 'deadline' are returned in parse-tree format, they should be interpreted first (but thats another function-call affecting speed?). Furthermore, to achieve real claritiy, the classification of properties in Org-mode should be checked again for completeness and consistency. E.g. the 'ID' property set by 'org-id' does not appear in any 'org--properties' variable and thus would falsely be treated as user/application property. Properties in 'org-special-properties' are upcase and don't always match the names of the (downcase) properties set by the parser. There is no variable for the class of properties that really only serve the parser/export framework (:beg, :end, :content-beg: etc.). > If you can explore this, that'd be great. As a little test I switched Agenda from day to year mode with (uncompiled) old and new version. I checked with #+begin_src emacs-lisp (symbol-file 'org-entry-properties) #+end_src that uncompiled versions are used, and with ,---- | C-h f org-entry-properties `---- which version is loaded. The results are *suspiciously* similar, but the checks indicated the new version was loaded during second test. * test-call (in agenda day-view) #+begin_src emacs-lisp (benchmark-run nil (org-agenda-change-time-span 'year)) #+end_src ** old (uncompiled) (54.418716989 94 12.718539017000012) ** new (uncompiled) (53.862527422 82 12.037524198) -- cheers, Thorsten