I have a use case where I tag a particular node in my Org-mode document with a unique hash. I then want to be able to programmatically access that node and append something to it. To that effect I wrote an Elisp function that returns a list of nodes with matching tags (this list should contain a single element in the non-pathological case):
(cl-defun get-node-by-tag (tag) "Given TAG, search the designated Org file and return a list of nodes with matching tags." (with-temp-buffer (insert-file-contents *org-notes-file*) (let ((contents (org-element-parse-buffer))) (labels ((extract (el) (let ((c (org-element-contents el))) (append (when (member tag (org-element-property :tags el)) (list el)) (mapcan #'extract (org-element-contents el)))))) (extract contents)))))
I then get the result, which is of the form:
((headline (:raw-value "TODO Jake VanderPlas - Python Data Science Handbook" :begin 10089 :end 10343 :pre-blank 0 :contents-begin 10190 :contents-end 10343 :level 5 :priority nil :tags ...
and use its
:end property to position myself at the end of that node.
Now here's the problem. I wrote the code on my work Emacs (27.2, running on Win 10), where it works fine. When I tried running it on my home machine (Emacs 27.1, running on PureOS), I found that the Org Element API returns results that are off by 2. The files on which I operate are different on both systems, but that shouldn't make a difference. One thing that came to my mind is the newline incompatibility (
LF in Unix vs.
CRLF in DOS/Windows), but I find it hard to believe the API would fail to take this into account. So I'm at a loss as to why the results are off. I'll appreciate any suggestions.
EDIT: As per @NickD's comment below, I'm attaching Org versions:
- Home system (erroneous):
- Work system (correct):
So the only difference here is the OS on which they run. And yes, the result is obviously wrong, i.e. I end up at the next node.