[BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Benjamin McMillan]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

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


The issue arises from the code for skipping clock lines, which does so by
checking if point is looking at (concat "[ \t]*$" "\\|" org-clock-line-re).
I'm not sure of the intention of the first alternative, the "[ \t]*$", but
it matches an empty line, and so the loop advances point to the next line,
until reaching the next heading in the case above.
Removing that from the regexp appears to fix the issue.

If this change is fine, then I am happy to provide a patch.
Thanks,
Ben

[-- Attachment #2: Type: text/html, Size: 937 bytes --]

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Ihor Radchenko]

Benjamin McMillan <mcmillanbb@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 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 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>

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Benjamin McMillan]

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

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 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Benjamin McMillan <mcmillanbb@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
> 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 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>
>

[-- Attachment #2: Type: text/html, Size: 3222 bytes --]

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Ihor Radchenko]

Benjamin McMillan <mcmillanbb@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Benjamin McMillan]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

I confused the issue in my response, and want to clear it up. As you say,
when the heading has no contents, "after metadata" is the next headline.
However, my problem is if heading 1 contains several blank lines:
* Heading 1
:PROPERTIES:
:ID: 111111
:END:




* Heading 2
In this example, a call of (org-end-of-meta-data) places point on the first
blank after :END:, in agreement with the docstring. On the other hand,
(org-end-of-meta-data t) places point all the way to heading 2, which is
not what the docstring says.
This mismatch caused me some headache. However, the suggestion to move back
lines is clever, and solves my problem.

Granted that it is not worth changing behavior of the function, would it be
reasonable to update the docstring? Something like
"When optional argument FULL is t, also skip planning information,
clocking lines, any kind of drawer, and blank lines.

When FULL is non-nil but not t, skip planning information,
properties, clocking lines, logbook drawers, and blank lines."

[-- Attachment #2: Type: text/html, Size: 1104 bytes --]

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Ihor Radchenko]

Benjamin McMillan <mcmillanbb@gmail.com> writes:

> Granted that it is not worth changing behavior of the function, would it be
> reasonable to update the docstring? Something like
> "When optional argument FULL is t, also skip planning information,
> clocking lines, any kind of drawer, and blank lines.

> When FULL is non-nil but not t, skip planning information,
> properties, clocking lines, logbook drawers, and blank lines."

Yes. More precise docstring is certainly welcome.
Would you be interested to submit a patch?

-- 
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>

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Benjamin McMillan]

[-- Attachment #1.1: Type: text/plain, Size: 917 bytes --]

Sure, here is the patch.

On Sun, Oct 20, 2024 at 6:03 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Benjamin McMillan <mcmillanbb@gmail.com> writes:
>
> > Granted that it is not worth changing behavior of the function, would it
> be
> > reasonable to update the docstring? Something like
> > "When optional argument FULL is t, also skip planning information,
> > clocking lines, any kind of drawer, and blank lines.
>
> > When FULL is non-nil but not t, skip planning information,
> > properties, clocking lines, logbook drawers, and blank lines."
>
> Yes. More precise docstring is certainly welcome.
> Would you be interested to submit a patch?
>
> --
> 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>
>

[-- Attachment #1.2: Type: text/html, Size: 1583 bytes --]

[-- Attachment #2: 0001-lisp-org.el-org-end-of-meta-data-Improve-docstring.patch --]
[-- Type: application/octet-stream, Size: 1660 bytes --]

From f93d8207ae54248bd2ecaabab93291b1a312d947 Mon Sep 17 00:00:00 2001
From: Benjamin McMillan <mcmillanbb@gmail.com>
Date: Tue, 22 Oct 2024 22:06:22 +0900
Subject: [PATCH] lisp/org.el (org-end-of-meta-data): Improve docstring

* lisp/org.el (org-end-of-meta-data): Clarify that a call of
org-end-of-metadata with non-nil argument FULL will skip blank lines
in addition to other meta-data.

Link: https://lists.gnu.org/archive/html/emacs-orgmode/2024-10/msg00243.html
[TINYCHANGE]
---
 lisp/org.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 7651c0832..a76281ad8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -21765,10 +21765,10 @@ When TO-HEADING is non-nil, go to the next heading or `point-max'."
   "Skip planning line and properties drawer in current entry.
 
 When optional argument FULL is t, also skip planning information,
-clocking lines and any kind of drawer.
+clocking lines, any kind of drawer, and blank lines
 
 When FULL is non-nil but not t, skip planning information,
-properties, clocking lines and logbook drawers."
+properties, clocking lines, logbook drawers, and blank lines."
   (org-back-to-heading t)
   (forward-line)
   ;; Skip planning information.
@@ -21783,7 +21783,7 @@ properties, clocking lines and logbook drawers."
       (let ((end (save-excursion (outline-next-heading) (point)))
 	    (re (concat "[ \t]*$" "\\|" org-clock-line-re)))
 	(while (not (eobp))
-	  (cond ;; Skip clock lines.
+	  (cond ;; Skip clock lines and blank lines.
 	   ((looking-at-p re) (forward-line))
 	   ;; Skip logbook drawer.
 	   ((looking-at-p org-logbook-drawer-re)
-- 
2.46.0

Re: [BUG] A call of (org-end-of-meta-data t) goes too far in a heading with only whitespace

[Ihor Radchenko]

Benjamin McMillan <mcmillanbb@gmail.com> writes:

> Sure, here is the patch.

Thanks!
Applied, onto bugfix.
I tweaked the commit message a bit, `quoting' the function name and
changing the thread link to point to orgmode.org/lisp (so that we also
keep the message ID in the URL for more robustness)
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix&id=3a6b14806e8

Fixed.

-- 
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>