From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sNsXAlXaoGCBdwAAgWs5BA (envelope-from ) for ; Sun, 16 May 2021 10:39:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 5ptIOVTaoGDGYwAAB5/wlQ (envelope-from ) for ; Sun, 16 May 2021 08:39:48 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4D337EF57 for ; Sun, 16 May 2021 10:39:48 +0200 (CEST) Received: from localhost ([::1]:50998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liCJP-0001Lc-FQ for larch@yhetil.org; Sun, 16 May 2021 04:39:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liCHx-0001LL-DE for emacs-orgmode@gnu.org; Sun, 16 May 2021 04:38:17 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:53415) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liCHn-0005qF-Pb for emacs-orgmode@gnu.org; Sun, 16 May 2021 04:38:16 -0400 Received: (Authenticated sender: admin@nicolasgoaziou.fr) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 9BBB3100002; Sun, 16 May 2021 08:38:03 +0000 (UTC) From: Nicolas Goaziou To: Ihor Radchenko Subject: Re: Question about Org syntax References: <87mtsvxs94.fsf@localhost> <877djz17cm.fsf@nicolasgoaziou.fr> <87h7j3xg3g.fsf@localhost> Mail-Followup-To: Ihor Radchenko , emacs-orgmode@gnu.org Date: Sun, 16 May 2021 10:38:02 +0200 In-Reply-To: <87h7j3xg3g.fsf@localhost> (Ihor Radchenko's message of "Sun, 16 May 2021 16:01:07 +0800") Message-ID: <87y2cfysyd.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.178.231; envelope-from=mail@nicolasgoaziou.fr; helo=relay11.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621154388; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=IO5n4UXzvUIvN51PxH1kN/TN6Uk9Fjh58VfwrCgiFnU=; b=SUfhf/vQzboXns2hZszOIXeNe5fB4AeM+2wDzHWSmsNwIKvkf+I3z2hK+yc2WhSbTw7wg7 +utyF345+7V5J+i7s8D/OZ8zCNekc8pH1gE262cypUBaCr5Bnpsne6t+LjBlYoZK0o3ZQ1 TkliTJFn44fUXfUgC4zj3jp/CkZCfn1UBdVyM6aLd/+5WZQxf5uFK4DY5C7HSiiG/HOchx 1A6xC/2hMKa96ZSoCDLnZWbmYTQHtRmMW8MjEhHfUWmN29tqPtKVB0IWg4T89WeOPLzzq9 S5Q71N0h6F5uUhKKOzlWMjDuIDQjytHs3D8KOTTTOMQLCn/LRv1gWoCQb3ifnw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621154388; a=rsa-sha256; cv=none; b=NKuh5mGol0dGAPGXTQICzZ6SUh+2D+ePEFnScb0JuHr3UsQBRY2y6mRlBP4hU9fWqJQWM6 3F8mJ4iH6WsOFrEbTFMrnSAa9V/FniJb2/yAvjn1CMJh/cDua32SGjSXjzZ1Pr65Pyu33b MwPhCwBPBTT6hNjIpwzZ9IjrOcnA2gqf71Kr33pg3FM/Ag0Xd8IaD7bfaPwg7SF2jmHJhL uTyWpeLVP0BTmrtcS7BDxJ8AVqv+NKoGzgmqAU6967LTSbwfhTiqo/q/93Z83+zjJWcqW2 rphIShxbHG4lVjYeFP+KE+VL0dBIY08GddMHayZhDDQBF1priBY8AH97AEttGA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -0.95 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 4D337EF57 X-Spam-Score: -0.95 X-Migadu-Scanner: scn0.migadu.com X-TUID: 0mTR93rcsCEb Ihor Radchenko writes: > Nicolas Goaziou 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: > > * Example headline > > :contents-begin of the parsed headline will be _after_ :end > > Or even > * 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