[FeatReq] New option for `org-entry-properties' WHICH argument?

[FeatReq] New option for `org-entry-properties' WHICH argument?

[Thorsten Jolitz]

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: [FeatReq] New option for `org-entry-properties' WHICH argument?

[Matt Lundin]

Thorsten Jolitz <tjolitz@gmail.com> 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: [FeatReq] New option for `org-entry-properties' WHICH argument?

[Bastien]

Hi Thorsten,

Thorsten Jolitz <tjolitz@gmail.com> 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: [FeatReq] New option for `org-entry-properties' WHICH argument?

[Thorsten Jolitz]

Bastien <bzg@gnu.org> writes:

Hi Bastien,

> Thorsten Jolitz <tjolitz@gmail.com> 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: [FeatReq] New option for `org-entry-properties' WHICH argument?

[Bastien]

Hi Thorsten,

Thorsten Jolitz <tjolitz@gmail.com> 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: [FeatReq] New option for `org-entry-properties' WHICH argument?

[Thorsten Jolitz]

Bastien <bzg@gnu.org> writes:

> Hi Thorsten,
>
> Thorsten Jolitz <tjolitz@gmail.com> 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