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

2014-07-29 Thread Bastien
Hi Thorsten,

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

2014-07-29 Thread Thorsten Jolitz
Bastien b...@gnu.org writes:

 Hi Thorsten,

 Thorsten Jolitz tjol...@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




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

2014-07-28 Thread Bastien
Hi Thorsten,

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

2014-07-28 Thread Thorsten Jolitz
Bastien b...@gnu.org writes:

Hi Bastien,

 Thorsten Jolitz tjol...@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




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

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

2014-06-26 Thread Matt Lundin
Thorsten Jolitz tjol...@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