From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 6GAPL0VQEWc2CgAA62LTzQ:P1 (envelope-from ) for ; Thu, 17 Oct 2024 17:58:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 6GAPL0VQEWc2CgAA62LTzQ (envelope-from ) for ; Thu, 17 Oct 2024 19:58:29 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OsdYNP56; 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=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729187909; 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=jRmnCYw6LG/t5SZ0hpXyrAXD4VteEHcuDzGVFzulbr0=; b=Vy8fpg4NIv3Uqk0z1tMw0p2YweJcbxTpQ1D3+P7U/+b1NhNI7plnsYRUOCoC7cOidsnPbV 2l1NTteOkHJUcg4pdjNoA6G58p7UVoJ+AaJTNU04lW353Uj04YKahjTkoj8ICkEa2K/Qxt vyeBogL96VXEEsyXwwKkCOy73jmqK8zbRItKMgguRsuknbWV02qB6yih9VSTxTcBNcFYYp /KHEAmlDKIDntNoJc5M0OyJegez93QH75XwnRuaHV7dXw79LBnTBMxFm86yvJlRkY9hDJ/ 8OcyJA+7wFnb5sb1TaNxi5jyDU1ANtkUH6eNTqU7Mv50Sx7Ob4yZ7prsvOA9Gg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OsdYNP56; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729187909; a=rsa-sha256; cv=none; b=HOxq7B1qknbjxaGgJiXU3KnF7Zhw93B8kfaB/+i1LY8uQSgNEfGvewXKcttGbH+fHijBCp BrRepXeNwhX88ysQfgk5quUvstk/cVepDM65qHCrayn7oG5oFwxkBwb5ZyVZei9BVD1PJP upa2ts3oEvQ80nHwhxOn0sIBZbnW1y3nZmsCxRcHtpPjW3mn7U+SOn58h2rc37moS3RvYU B6UrH9yHZAhgTduz89YQF/vFGwG0dqrFY/yqgbA6Eu+a60FY6RNRhVHPKBjOhcR+pOXWPk uR8Dh7co7P11oeNy6lE28AP6Cikun6v1VPm9BVK8HZmKjCCanmJ13gyoRYY8kA== 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 EDEFF8E187 for ; Thu, 17 Oct 2024 19:58:28 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t1UkP-0008Cn-9H; Thu, 17 Oct 2024 13:57:17 -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 1t1UkO-0008CE-7C for emacs-orgmode@gnu.org; Thu, 17 Oct 2024 13:57:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1UkK-00042O-P8 for emacs-orgmode@gnu.org; Thu, 17 Oct 2024 13:57:15 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 39ADE240101 for ; Thu, 17 Oct 2024 19:57:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1729187830; bh=GRGudgrJj/2m1trlH9FzJE+YEdDGsCHpRBUHT/mQsUc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=OsdYNP5687I8gX2Wzl3fJ6wxe+O0RTHPSWtEYsGxD7DSwcS9Labfs515jq3D2/Jmv mfS8YEr4gYj+t6pfq8acJtPxCMVeX6RD8pZkHgWPNzS6513g2zkLMcv8zzjkQKAXLa /Rd7hvJIBBmLAreih+jWx/ZT3BgvhHYISQAtafFFIurk5WeEyH7oWfuzdwsQc2jcZ9 m1KgOtXVTBqQQOBPd4sQRcoFoW3OTCtp/tTlCDdc5Nuj+PVNxmBmT9sptrK/I0H+ba K33KSCf7hCu2uFa6ruJ05fXAHCceLF/qlqJsYJR7YouY3Ed/G+cbEgMQBly3eHUS+f w6yv8fsJMlHjA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XTwX52g8nz9rxP; Thu, 17 Oct 2024 19:57:09 +0200 (CEST) From: Ihor Radchenko To: Benjamin McMillan Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace In-Reply-To: References: <87jzedsfxx.fsf@localhost> Date: Thu, 17 Oct 2024 17:58:52 +0000 Message-ID: <877ca6zk4j.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -1.20 X-Spam-Score: -1.20 X-Migadu-Queue-Id: EDEFF8E187 X-TUID: LJYVxAkiaNxJ Benjamin McMillan writes: > 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. Nope. It should "Skip planning line and properties drawer in current entry.", as per docstring. In other words, after the metadata. Sometimes, "after metadata" is on the next headline. For example, when headline has no contents at all: * Heading 1 * Immediately heading 2 > I presume the test is to capture desired behavior when > org-blank-before-new-entry is true? I doubt so. But I do not know exact reason. > 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. Surely not. (1) I still see not reason to break the existing behavior (and annoy users used to the existing one); (2) metadata is often followed by actual text in entry - org-blank-before-new-entry makes 0 sense in such scenarios; (3) org-end-of-metadata must not edit the buffer. It would be unexpected. > 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. You are free to move back if you are using `org-end-of-meta-data' from Elisp. This will be just as accurate. For now, I see no bug in your report. Everything works as per docstring. Canceled. I suspect that the problem you are really trying to solve is not with `org-end-of-meta-data', but with some other function/command that is using it. If I am right, we may better discuss that problem. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at