From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 0NJFHHf7EGduRQEAqHPOHw:P1 (envelope-from ) for ; Thu, 17 Oct 2024 11:56:39 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 0NJFHHf7EGduRQEAqHPOHw (envelope-from ) for ; Thu, 17 Oct 2024 13:56:39 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ED3GgSop; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729166199; 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:dkim-signature; bh=nyPzdv6GJy3d9DwJSQnH0cSc/QZh26XChbWAtBYsPl8=; b=FX2hv3aT6kX4hzW9APU+3FCE9DUqueOMPtTgWwauyz1iO8AuaXRhQE77p5Rb+fRkFSbF1r 39/4882lqrye3aAYFnXWQBiZV2vP3N96y573YycdV5E53k04Tk/Pk/HewKG1MSGcSf/2OM v/eqhqcZ5VtOj8wYPhCtrZX8olxiflixSOJCSE9PCPc1GsAbAZSQJ7gGVAFDJglGxiJJKf rNadlxVHJhC/Y7YyllaJMVDj/aHis0jncDcYMtPRHh+6JzpwS6yN+KyV9IFo8IdMITeYAP PhaZVR209Tsrhl022UNWCdm383wqIjntpjn8WrHu3cT52tXhJoH6zju80Zb2dA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729166199; a=rsa-sha256; cv=none; b=WgCgltMMPqM7Zn1PG2Uh8Yz1D3WyW2/L0tonFOjF1bcPcEzFid7d918K8oJDKt4NyaIYXM sZGgXdhoWKQAu/IEr6kND45iV7BQZXtEgQ9GgKR2vW1wfQQFRhlEL4/h40px6e1iKXM1vl JqhhKzSWoaqVmZ8GD9P0ugRsm0BvN9oaB3SJ3SgNRfTT8dFT8b+9heo5Tw8cDM2uRt1rYg x2/SSEPuT8l5b7o0b0iKJs+aa3pUQ0nC1L+B9D1a2aNF1qJkoQMbH4NG+8935Th50w740t cnzEQCu6JCV10dwJTgixI6NriNlLMKMXz0C2ieiJPh6jrTTI6cNuiXy9v2XHcw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ED3GgSop; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com 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 104C0106E for ; Thu, 17 Oct 2024 13:56:38 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t1P6e-0001Yi-PQ; Thu, 17 Oct 2024 07:55:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1P6d-0001Ya-2D for emacs-orgmode@gnu.org; Thu, 17 Oct 2024 07:55:51 -0400 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t1P6a-0008TS-LM for emacs-orgmode@gnu.org; Thu, 17 Oct 2024 07:55:50 -0400 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e28fa2807eeso808335276.1 for ; Thu, 17 Oct 2024 04:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729166147; x=1729770947; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nyPzdv6GJy3d9DwJSQnH0cSc/QZh26XChbWAtBYsPl8=; b=ED3GgSop5U+9E8oNZW8ggy+H4Ay+jcsy6GeAH0YtCV8zRd2cltl5wlAK0Deqswdb1S DX2lLqIvEN2a9/zpmdIh2+AruiCUm/JX7llx+J76MVcQnoWKKb2fYAGJdzsoMbPfg5TA PQZ1wZS3e9e+Mkrg+EF6a6iPM4A58fcpDCOuUA/M6UGAmUJHdSHwylrFRM8/jZhDCzrz +gPhL3en8ByrwVfBCoCRcU+NripZJMuEO5LL2Ffm5GOKpEFuiS43ikSXjaS9RAJQYEKw K/dPtm+ZUlmx5C/eiDKCcJzFrVM6j6nHER/pTsH+NSkA+RTfdhhhrGvli+6aI0hFH7Me Bfsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729166147; x=1729770947; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nyPzdv6GJy3d9DwJSQnH0cSc/QZh26XChbWAtBYsPl8=; b=seN57JkOt43qqiramGq28vSmY8TNm5eiBP/m7F5b+f301CKGzTiZ5V7bNrwsqP1gwZ 6iXtjIwsjRrI7E1A7vNkoqHJMo4LllNFaMRIBpgHT2ZSkZQhCnnjUnBH/9RKEnVMYrmn IYA/NU9ksRp02/Ueg5+sHyocpZT6fhtHtSowlvyimuHKle/gbZXoYprLitpArmnWsJWq UAk9Vj9C5oP7dcI1ss/CdXMTMm0pwzvjQiNhpL0bdC3rZzY/Wt7yh0V4wmxdOuq8LQ6C 2+R2DLQVtU95Zg4L5AxnCu+FSOtJijC256Ru+45ymT6MI162puccBGq0+mZ2ure/bqZh v8iA== X-Gm-Message-State: AOJu0YyFf/Z7TfP/J20jsUCaCNoBZGDHgqtP2bEnP9HkEUcTXAIbaV7D SYCNnBdGwfOKiIu6CfKpgBAp74jPyqwheGXna2qPsvKVMlqspuAjKqmYeiVSPcB6j4yLwrNXuUC RyPDMZlzPyTW0u/bEEoqYtqpmTbo= X-Google-Smtp-Source: AGHT+IFRwcxWoCEtiHf2/DE3x5TPsKr4fn7WyJnHERjNJaf39HlrPUnQvY8yxhBWvA5P3+3/5Ap/SodX6St66z0OLxE= X-Received: by 2002:a05:690c:6609:b0:6e2:1a56:bff8 with SMTP id 00721157ae682-6e347b30d6dmr171290207b3.36.1729166146834; Thu, 17 Oct 2024 04:55:46 -0700 (PDT) MIME-Version: 1.0 References: <87jzedsfxx.fsf@localhost> In-Reply-To: <87jzedsfxx.fsf@localhost> From: Benjamin McMillan Date: Thu, 17 Oct 2024 20:55:20 +0900 Message-ID: Subject: Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="000000000000f099c40624aaddad" Received-SPF: pass client-ip=2607:f8b0:4864:20::b29; envelope-from=mcmillanbb@gmail.com; helo=mail-yb1-xb29.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -3.36 X-Spam-Score: -3.36 X-Migadu-Queue-Id: 104C0106E X-Migadu-Scanner: mx13.migadu.com X-TUID: N46aY9KYutnc --000000000000f099c40624aaddad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My understanding is that org-end-of-meta-data should put point at the start of the 'real' contents of a heading. Meaning the first point where I might start making notes under a heading. This expectation isn't matched in the example I give (which is different from the mentioned test). In my example, there is a heading, then several blank lines, then another heading at the same level as the first. A call to (end-of-meta-data t) goes all the way to the second heading, which surely should not count as contents of the first heading. For me, expected behavior is somewhere inside the contents of the heading. I presume the test is to capture desired behavior when org-blank-before-new-entry is true? If that's correct, then when org-blank-before-new-entry is true, maybe a call of (end-of-meta-data t) should skip to two lines after the metadata (possibly adding lines if necessary?) In contrast, I disable org-blank-before-new-entry, and want point to go literally to the end of meta data, even if I have some blanks before existing contents. I apologize if this seems nitpicky, but the structured nature of an org document allows for extremely accurate motion commands, and use of end-of-meta-data is an important part of that. (And apologies Ihor for resending this to you, I managed to not click reply-all the first time around.) On Sat, Oct 12, 2024 at 8:43=E2=80=AFPM Ihor Radchenko wrote: > Benjamin McMillan writes: > > > Specifically, a call to (org-end-of-meta-data t) with point at the > on > the > > following tree will go all the way to the next heading. > > In contrast, a call to just (org-end-of-meta-data), without the FULL > flag, > > will go to the beginning of heading content, as expected. > > * >heading > > > > > > * another heading > > This is intentional. > > We have a test: > > ;; With option argument, skip empty lines, regular drawers and > ;; clocking lines. > (should > (org-test-with-temp-text "* Headline\n\nContents" > (org-end-of-meta-data t) > (looking-at "Contents"))) > > May you please elaborate why you consider the current behavior to be a bu= g? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --000000000000f099c40624aaddad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding is that org-end-of-meta-data should put p= oint at the=20 start of the 'real' contents of a heading. Meaning the first point = where I might start making notes under a heading.

This expectation=20 isn't matched in the example I give (which is different from the=20 mentioned test). In my example, there is a heading, then several blank=20 lines, then another heading at the same level as the first. A call to=20 (end-of-meta-data t) goes all the way to the second heading, which=20 surely should not count as contents of the first heading. For me,=20 expected behavior is somewhere inside the contents of the heading.

I= presume the test is to capture desired behavior when org-blank-before-new-= entry is true?
If that's correct, then when org-blank-before-new-entry is true, maybe a= =20 call of (end-of-meta-data t) should skip to two lines after the metadata (possibly adding lines if necessary?)
In contrast, I disable=20 org-blank-before-new-entry, and want point to go literally to the end of meta data, even if I have some blanks before existing contents.

I apologize if this seems nitpicky, but the structured nature of an org=20 document allows for extremely accurate motion commands, and use of=20 end-of-meta-data is an important part of that.
(And apologies Iho= r for resending this to you, I managed to not click reply-all the first tim= e around.)

On Sat, Oct 12, 2024 at 8:43=E2=80=AFPM Ihor Radchenko = <yantar92@posteo.net> wrot= e:
Benjamin McMi= llan <mcmillan= bb@gmail.com> writes:

> Specifically, a call to (org-end-of-meta-data t) with point at the >= ; on the
> following tree will go all the way to the next heading.
> In contrast, a call to just (org-end-of-meta-data), without the FULL f= lag,
> will go to the beginning of heading content, as expected.
> * >heading
>
>
> * another heading

This is intentional.

We have a test:

=C2=A0 ;; With option argument, skip empty lines, regular drawers and
=C2=A0 ;; clocking lines.
=C2=A0 (should
=C2=A0 =C2=A0(org-test-with-temp-text "* Headline\n\nContents" =C2=A0 =C2=A0 =C2=A0(org-end-of-meta-data t)
=C2=A0 =C2=A0 =C2=A0(looking-at "Contents")))

May you please elaborate why you consider the current behavior to be a bug?=

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--000000000000f099c40624aaddad--