Ihor Radchenko <yanta...@gmail.com> writes: > Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> It should be a paragraph. I'll fix it soon. >> >> Note the problem can be reproduced with only >> >> * test >> :end: > > Thanks!
Fixed. Thank you. > Also, I have few more questions (or maybe bug reports) about > syntax/parsing: > > 1. Does org-element--current element suppose to return (paragraph ...) > on empty buffer? It is undefined. `org-element-current-element' is an internal function being called at the beginning of "something". However, `org-element-at-point' is expected to return nil in an empty buffer. > 2. Some of the element parsers honour LIMIT argument partially. Part of > the parsing is typically done using looking-at (ignoring the LIMIT) > and part is honouring it. This can backfire when LIMIT is before > first characteristic line of the element. For example take headline > parser: > > <point>* Example<limit> headline > > :contents-begin of the parsed headline will be _after_ :end > > Or even > <point><limit>* example headline > > :contents-begin is equal to :begin, sometimes leading to infinite > loops in org-element--parse-to called by org-element-cache (hence, > known bug with Emacs hangs when org-element-use-cache is non-nil) > > Some of the parsers potentially causing similar issues are: > > In particular, org-element-footnote-definition-parser, > org-element-headline-parser, org-element-inlinetask-parser, > org-element-plain-list-parser, org-element-property-drawer-parser, > org-element-babel-call-parser, org-element-clock-parser, > org-element-comment-parser, org-element-diary-sexp-parser, > org-element-fixed-width-parser, org-element-horizontal-rule-parser, > org-element-keyword-parser, org-element-node-property-parser, > org-element-paragraph-parser, ... LIMIT is not a random position in the buffer. It is supposed to be the end of the parent element, or (point-max). It is a bug (in the parser or in the cache) if it ends up being anywhere else. > 3. Some of the element parsers ignore LIMIT altogether: > org-element-item-parser, org-element-section-parser... `org-element-section-parser' actually recomputes LIMIT since it calls `outline-next-heading'. This is sub-optimal and could probably be removed. `org-element-item-parser' is called in `item' mode, i.e., right after `org-element-plain-list-parser', which already takes care of LIMIT. No need to handle it twice. > Is there any reason behind this? I though that parsing narrowed > buffer is supposed to honour narrowing. Also, ignoring LIMIT might > cause issue when trying to parse only visible elements. No, parsing ignores any narrowing, hence the copious use of `org-with-wide-buffer' or `org-with-point-at'. Narrowing is here to help the user focus on a part of the document, not to cheat on the surrounding syntax. As an example Here is an example: what do you think about it? Narrowing the buffer to ": what do you think about it?" for reasons should not trick the parser into thinking you're in a fixed width area. Regards, -- Nicolas Goaziou