Re: Question about Org syntax

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Ihor Radchenko <yantar92@gmail.com> writes:

> Nicolas Goaziou <mail@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