Max Nikulin <maniku...@gmail.com> writes: > With equivalent patch (attached one has additional differences in spaces > around) my particular case works. I have no idea which additional > scenarios it may affect. I did not test the patch extensively. I faced > the issue while I was preparing a patch to fix storing double #CUSTOM_ID > links.
I pushed the patch upstream. > P.S. I am puzzled that `org-element-at-point' returns paragraph even > when patch is not applied. After such call `org-store-link' does what I > expect. However "after undo" erroneous state survives emacs restart, > thanks to org-persist, I believe. The bug was in very specific case. org-element-at-point now has a special fast mode of operation when CACHED-ONLY argument is non-nil. In this mode, it does not try to parse anything, but only checks the nearest cached element and returns it if point is at the element beginning, within +begin/end line of the element, or inside a non-greater element. The error happened when the cached element was a section and point was within blank lines at the end of the section exactly one symbol before the following headline. In such cases, org-element-at-point must follow some special rules (see comments in org-element--parse-to), but it did not in this specific scenario. On top of that, org-element-parse-to cannot return section and the current code assumes that we ever attempt to return section when point is at the beginning of section. So, it returns (org-element-at-point (1+ pos)) instead. Hence, the next headline was wrongly returned when (1) point is 1- beginning of next headline (2) we are within blank lines at the end of section (3) some edit in buffer just cleared everything in cache inside current section (4) org-element-at-point is called with non-nil CACHED-ONLY argument. Just calling org-element-at-point did not trigger error. You would need to call (org-element-at-point nil 'cached) Best, Ihor
