emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Question about Org syntax
Date: Sun, 16 May 2021 10:38:02 +0200	[thread overview]
Message-ID: <87y2cfysyd.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87h7j3xg3g.fsf@localhost> (Ihor Radchenko's message of "Sun, 16 May 2021 16:01:07 +0800")

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


  reply	other threads:[~2021-05-16  8:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16  3:38 Ihor Radchenko
2021-05-16  7:11 ` Nicolas Goaziou
2021-05-16  8:01   ` Ihor Radchenko
2021-05-16  8:38     ` Nicolas Goaziou [this message]
2021-05-23  3:50       ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2cfysyd.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@gmail.com \
    --subject='Re: Question about Org syntax' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).