[O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Hi List, 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' with semantics/implementation similar to this (there are surely cl-xxx filter-functions that can do this as one-liner): #+begin_src emacs-lisp (delq nil (mapcar (lambda (--cons) (unless (or (member (car --cons) org-default-properties) (member (car --cons) org-special-properties)) --cons)) (org-entry-properties))) #+end_src What do you think? -- cheers, Thorsten
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Thorsten Jolitz writes: > Hi List, > > 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' [..] > > What do you think? +1 It would help in extracting user data when such data is interspersed with org properties (e.g., LAST_REPEAT). Matt
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Hi Thorsten, 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 see how it would be useful. Can you provide a patch for this? Thanks, -- Bastien
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
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
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Hi Thorsten, Thorsten Jolitz writes: > - ask the maintainer for a hint towards a smarter less intrusive >solution? Well, the maintainer will be on holiday starting from tonight until August, 18th, so let's wait by then? If you happen to make progress in the meantime, that'd be good too. Thanks, -- Bastien
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Bastien writes: > Hi Thorsten, > > Thorsten Jolitz writes: > >> - ask the maintainer for a hint towards a smarter less intrusive >>solution? > > Well, the maintainer will be on holiday starting from tonight until > August, 18th, so let's wait by then? > > If you happen to make progress in the meantime, that'd be good too. Have fun - and lets see ... -- cheers, Thorsten
