From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [FeatReq] New option for `org-entry-properties' WHICH argument? Date: Mon, 28 Jul 2014 23:11:36 +0200 Message-ID: <8761ihw5mf.fsf@gmail.com> References: <87ha37jrip.fsf@gmail.com> <87wqaxz98v.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBsD8-0006LC-4G for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 17:12:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBsD1-0001Yy-Iv for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 17:11:58 -0400 Received: from plane.gmane.org ([80.91.229.3]:60664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBsD0-0001Yu-Ss for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 17:11:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XBsCz-0001n1-Mx for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 23:11:49 +0200 Received: from e178058217.adsl.alicedsl.de ([85.178.58.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jul 2014 23:11:49 +0200 Received: from tjolitz by e178058217.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jul 2014 23:11:49 +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: > >> what about adding one more option for WHICH >> >> ,----[ C-h f org-entry-properties RET ] >> | org-entry-properties is a compiled Lisp function in `org.el'. >> | >> | (org-entry-properties &optional POM WHICH SPECIFIC) >> | [...] >> | If WHICH is nil or `all', get all properties. If WHICH is >> | `special' or `standard', only get that subclass. If WHICH >> | is a string only get exactly this property. SPECIFIC can be a >> | string, the >> | specific property we are interested in. Specifying it can speed >> | things up because then unnecessary parsing is avoided. >> `---- >> >> that would filter out all Org related properties, i.e. the properties >> the system itself uses, and thus return only the application related >> properties? >> >> E.g. option 'non-org' > > You mean `non-special' or `non-standard'? I.e. all properties that > are not listed as special properties? yes, I mean filtering out as many special, standard or otherwise 'wellknown' system-properties and return just the remaining application/user-defined properties. > Yes, I see how it would be useful. > > Can you provide a patch for this? I had a look, and its not as trivial as I thought. This function clearly predates the new parser, it does not make use of variables like ,---- | org-custom-properties | org-default-properties | org-global-properties | org-global-properties-fixed | org-special-properties | org-element-document-properties | org-taskjuggler-default-global-properties `---- and the way it is written I cannot simply add another 'case' or 'cond' statement to get all properties that are not special or standard. So what would be the strategy here? - complete rewrite based on the new parser (and making use of the above mentioned variables)? - some heavy refactoring, on the line of adding let-bindings for the special and standard properties and introducing a '(case which ()...) expression with fallback to 'all? - ask the maintainer for a hint towards a smarter less intrusive solution? -- cheers, Thorsten