[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about Org syntax
From: |
Nicolas Goaziou |
Subject: |
Re: Question about Org syntax |
Date: |
Sun, 16 May 2021 10:38:02 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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