Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Recipe:
1. Create an org file with the following contents:

* 1
** 2

2. emacs -Q
3. Open the file
4. Put the point at the end of the second headline
5. M-: (message "%s" (org-element-at-point))

Expected behaviour:

According to org-element-at-point docstring, "Properties depend on
element or object type, but always include :begin, :end, :parent and
:post-blank properties.". Hence, it is expected to have :parent property
set to the first headline.

Observed behaviour:

(headline (:raw-value 2 :begin 6 :end 13 :pre-blank 0 :contents-begin
nil :contents-end nil :level 2 :priority nil :tags nil :todo-keyword nil
:todo-type nil :post-blank 2 :footnote-section-p nil :archivedp nil
:commentedp nil :post-affiliated 6 :title 2))

No :parent property is returned.

Best,
Ihor


Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2019-12-16
Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> According to org-element-at-point docstring, "Properties depend on
> element or object type, but always include :begin, :end, :parent and
> :post-blank properties.".

Probably the docstring needs to be adapted - Nicolas knows this area
better than me.

Best,

-- 
 Bastien

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

> Probably the docstring needs to be adapted - Nicolas knows this area
> better than me.

Do you mean that :parent property may not always be present?

If so, it is quite disappointing. It would be helpful to be able to find
parent of any element at point (especially, in conjunction with
org-element-cache). At least, optionally. 

I was counting on this feature to try speeding up my agenda generation
(using org-element-cache).

Best,
Ihor


Bastien <bzg@gnu.org> writes:

> Hi Ihor,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> According to org-element-at-point docstring, "Properties depend on
>> element or object type, but always include :begin, :end, :parent and
>> :post-blank properties.".
>
> Probably the docstring needs to be adapted - Nicolas knows this area
> better than me.
>
> Best,
>
> -- 
>  Bastien

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Ihor Radchenko <yantar92@gmail.com> writes:

>> Probably the docstring needs to be adapted - Nicolas knows this area
>> better than me.
>
> Do you mean that :parent property may not always be present?

I don't know, I hope Nicolas can handle this.

-- 
 Bastien

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

>> Probably the docstring needs to be adapted - Nicolas knows this area
>> better than me.
>
> Do you mean that :parent property may not always be present?

`org-element-at-point' returns only a partial parse tree. It never goes
higher than the current top-level element, i.e., from an element, you
cannot go up to the headline just following :parent.

Luckily, headlines are exactly where you do _not_ need Element library.
`org-back-to-heading' and `org-up-heading-safe' will always be faster,
and as accurate. I.e., the code operating on headlines is usually
distinct from the code handling other elements.

> If so, it is quite disappointing. It would be helpful to be able to find
> parent of any element at point (especially, in conjunction with
> org-element-cache). At least, optionally. 

You can parse the full document and get all the :parent properties
filled. That's not the job for `org-element-at-point'.

> I was counting on this feature to try speeding up my agenda generation
> (using org-element-cache).

Note that `org-element-cache' was disabled a while ago because it could
introduce freezes. I think this is related to how this part handles
`before-change-functions' and `after-change-functions'. Anyway, YMMV.

Regards,

-- 
Nicolas Goaziou

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

> `org-element-at-point' returns only a partial parse tree. It never goes
> higher than the current top-level element, i.e., from an element, you
> cannot go up to the headline just following :parent.

Thanks for the clarification. I was not sure if it is intended.
I was mislead about this 2 times because of docstring, though it is
clear from the source code. 

> Luckily, headlines are exactly where you do _not_ need Element library.
> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
> and as accurate. I.e., the code operating on headlines is usually
> distinct from the code handling other elements.

Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of
my agenda generation time (I have really huge number of headings +
multiple custom skip functions). I was hoping to use cache for speed up. 

> You can parse the full document and get all the :parent properties
> filled. That's not the job for `org-element-at-point'.

I once tried to do exactly this, but I did not manage to figure out how
to obtain element at point from full parse tree (from inside an agenda
skip function). Is it possible?

> Note that `org-element-cache' was disabled a while ago because it could
> introduce freezes. I think this is related to how this part handles
> `before-change-functions' and `after-change-functions'. Anyway, YMMV.

I see... I don't know how useful the cache is except my idea about
using cache to speed up agenda. But I was stuck with the :parent
property issue and did not play much further since that time.

Best,
Ihor

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>>> Probably the docstring needs to be adapted - Nicolas knows this area
>>> better than me.
>>
>> Do you mean that :parent property may not always be present?
>
> `org-element-at-point' returns only a partial parse tree. It never goes
> higher than the current top-level element, i.e., from an element, you
> cannot go up to the headline just following :parent.
>
> Luckily, headlines are exactly where you do _not_ need Element library.
> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
> and as accurate. I.e., the code operating on headlines is usually
> distinct from the code handling other elements.
>
>> If so, it is quite disappointing. It would be helpful to be able to find
>> parent of any element at point (especially, in conjunction with
>> org-element-cache). At least, optionally. 
>
> You can parse the full document and get all the :parent properties
> filled. That's not the job for `org-element-at-point'.
>
>> I was counting on this feature to try speeding up my agenda generation
>> (using org-element-cache).
>
> Note that `org-element-cache' was disabled a while ago because it could
> introduce freezes. I think this is related to how this part handles
> `before-change-functions' and `after-change-functions'. Anyway, YMMV.
>
> Regards,
>
> -- 
> Nicolas Goaziou

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Nicolas Goaziou]

Ihor Radchenko <yantar92@gmail.com> writes:

> Thanks for the clarification. I was not sure if it is intended.
> I was mislead about this 2 times because of docstring, though it is
> clear from the source code.

I fixed the docstring. Thank you.

>> Luckily, headlines are exactly where you do _not_ need Element library.
>> `org-back-to-heading' and `org-up-heading-safe' will always be faster,
>> and as accurate. I.e., the code operating on headlines is usually
>> distinct from the code handling other elements.
>
> Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of
> my agenda generation time (I have really huge number of headings +
> multiple custom skip functions). I was hoping to use cache for speed
> up. 

Cache will not help you here. `org-up-heading-safe' and
`org-back-to-heading' are faster than `org-element-at-point' + cache.

Moreover, custom skip functions are a pain. They prevent any form of
caching during agenda creation. IMO, Agenda (or its re-implementation)
should do without them.

>> You can parse the full document and get all the :parent properties
>> filled. That's not the job for `org-element-at-point'.
>
> I once tried to do exactly this, but I did not manage to figure out how
> to obtain element at point from full parse tree (from inside an agenda
> skip function). Is it possible?

It is possible but not implemented.

>> Note that `org-element-cache' was disabled a while ago because it could
>> introduce freezes. I think this is related to how this part handles
>> `before-change-functions' and `after-change-functions'. Anyway, YMMV.
>
> I see... I don't know how useful the cache is except my idea about
> using cache to speed up agenda. But I was stuck with the :parent
> property issue and did not play much further since that time.

I once started to implement Agenda-specific caching, but stopped as it
would have entailed rewriting much of the Agenda code. It would have
been a pain. Even switching "org-agenda.el" to lexical binding is
difficult (and isn't done yet).

Some re-implementation of Agenda (e.g., org-super-agenda + org-ql) may
be better wrt caching.