[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
From: |
Thorsten Jolitz |
Subject: |
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument? |
Date: |
Mon, 28 Jul 2014 23:11:36 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Bastien <address@hidden> writes:
Hi Bastien,
> Thorsten Jolitz <address@hidden> 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