bug#81229: 32.0.50; (vc-mode) log-edit-generate-changelog-from-diff fails on org-mode file check-in

Ihor Radchenko <[email protected]> writes:

> Eli Zaretskii <[email protected]> writes:
>>> Because it is logical. Just as next-line signals user error when there
>>> is no next line. Org's version of end-of-defun signals user error when
>>> we are at the end. Useful for keyboard macros. This is a common pattern,
>>> although I only now learned that the default end-of-defun does not
>>> follow it.
>>
>> AFAIU, unlike next-line, end-of-defun does not have to move point, so
>> signaling and error when it cannot is not necessarily TRT.
>
> That's a good point. I was somewhat biased because I saw how Org
> implements it (via forward-paragraph equivalent). I will need to think
> about this.

I have been thinking about this for a while, and I am not convinced
about "does not have to move point".

end-of-defun in Elisp does not move point in one single case - at eob.
Further, `end-of-defun' docstring says "Move forward to next end of defun."
When is the "next end of defun" at eob? There is none.

So, as it is now, I see the behavior at eob undefined.
There is de-facto convention for the default end-of-defun that it does
not err at eob, but that's it.
IMHO, throwing a user error would be more useful.

That said, end-of-defun-*function* is supposed to do something slightly
different -
"... the function can assume that point is at the beginning of the defun body.
It should move point to the first position after the defun."
I have fixed end-of-defun-function in Org to behave as the docstring
demands. (Similar for beginning-of-defun-function).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7bd41df72

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
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>