emacs-orgmode
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]