Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes :end is incorrect #8

ndw opened this issue Feb 29, 2020 · 1 comment

Sometimes :end is incorrect #8

ndw opened this issue Feb 29, 2020 · 1 comment


Copy link

@ndw ndw commented Feb 29, 2020

Consider this org-mode file:

#+TITLE: Test Title

There’s still room for improvement:

+ A few big chunks of this file are still mostly verbatim copies from
  my old configuration file with little by way of new documentation.
+ There’s still a bunch of undocumented configuration in libraries in
  =~/.emacs.d/personal/*.el= that would benefit from greater

* heading

Insert something here.

I'm trying to walk through it, parsing each org element. Suppose I get to point 59.

If you goto point 59 and run (org-element-at-point), it will return something like this:

(plain-list (:type unordered :begin 59 :end 347
  :contents-begin 59 :contents-end 346 :structure ...)

If you run (om-parse-element-at 59), it will return something like this:

(plain-list (:type unordered :begin 59 :end 346
  :contents-begin 59 :contents-end 346 :structure ...)

Note that :end is one character short here. Unfortunately, if you run (om-parse-element-at 346), you'll discover that you get back the same plain-list and you're in an infinite loop.

Unfortunately, it isn't always one character short, so I don't think the solution is to always add one. But I haven't worked out from the output of om-parse-element-at when I should add one.

Bug or misundertanding on my part?


This comment has been minimized.

Copy link

@ndwarshuis ndwarshuis commented Feb 29, 2020

Nope, this is a bug.

Internally, all the parse functions call org-element--parse-elements using the :begin and :end properties obtained from org-element-at-point (or or-element-context in the case of objects). The problem is that org-element--parse-elements will return a section element that wraps whatever you really want (in this case a plain-list) and that section will have its :post-blank property set to non-zero if there are any blanks at the end. This means that anything inside the section will have :post-blank set to zero (otherwise those blanks at the end would be double-counted), which in this case makes it appear that the plain-list is one character shorter than it should be.

So what needs to happen is that any time we unwrap something from a section and return it, the :post-blank and :end properties may need to be passed into the wrapped element to preserve the boundaries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.