all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
@ 2019-12-16 12:17 Ihor Radchenko
  2020-02-05  7:19 ` Bastien
  0 siblings, 1 reply; 7+ messages in thread
From: Ihor Radchenko @ 2019-12-16 12:17 UTC (permalink / raw)
  To: emacs-orgmode


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/)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2019-12-16 12:17 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
@ 2020-02-05  7:19 ` Bastien
  2020-02-05  9:55   ` Ihor Radchenko
  0 siblings, 1 reply; 7+ messages in thread
From: Bastien @ 2020-02-05  7:19 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2020-02-05  7:19 ` Bastien
@ 2020-02-05  9:55   ` Ihor Radchenko
  2020-02-05 10:13     ` Bastien
  2020-02-05 12:55     ` Nicolas Goaziou
  0 siblings, 2 replies; 7+ messages in thread
From: Ihor Radchenko @ 2020-02-05  9:55 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2020-02-05  9:55   ` Ihor Radchenko
@ 2020-02-05 10:13     ` Bastien
  2020-02-05 12:55     ` Nicolas Goaziou
  1 sibling, 0 replies; 7+ messages in thread
From: Bastien @ 2020-02-05 10:13 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2020-02-05  9:55   ` Ihor Radchenko
  2020-02-05 10:13     ` Bastien
@ 2020-02-05 12:55     ` Nicolas Goaziou
  2020-02-05 13:49       ` Ihor Radchenko
  1 sibling, 1 reply; 7+ messages in thread
From: Nicolas Goaziou @ 2020-02-05 12:55 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2020-02-05 12:55     ` Nicolas Goaziou
@ 2020-02-05 13:49       ` Ihor Radchenko
  2020-02-05 14:46         ` Nicolas Goaziou
  0 siblings, 1 reply; 7+ messages in thread
From: Ihor Radchenko @ 2020-02-05 13:49 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: emacs-orgmode

> `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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* 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/)]
  2020-02-05 13:49       ` Ihor Radchenko
@ 2020-02-05 14:46         ` Nicolas Goaziou
  0 siblings, 0 replies; 7+ messages in thread
From: Nicolas Goaziou @ 2020-02-05 14:46 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-02-05 14:46 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-16 12:17 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
2020-02-05  7:19 ` Bastien
2020-02-05  9:55   ` Ihor Radchenko
2020-02-05 10:13     ` Bastien
2020-02-05 12:55     ` Nicolas Goaziou
2020-02-05 13:49       ` Ihor Radchenko
2020-02-05 14:46         ` Nicolas Goaziou

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.