From: Nicolas Goaziou <firstname.lastname@example.org> To: Ihor Radchenko <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Question about Org syntax Date: Sun, 16 May 2021 10:38:02 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <87h7j3xg3g.fsf@localhost> (Ihor Radchenko's message of "Sun, 16 May 2021 16:01:07 +0800") Ihor Radchenko <firstname.lastname@example.org> writes: > Nicolas Goaziou <email@example.com> 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
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).