Eli Zaretskii writes: >> Date: Sun, 25 Jun 2023 15:38:12 +0200 >> From: Daniel Martín via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of >> text editors" writes: >> >> > This is a regression from Emacs 28.2. >> > >> >> This is the first commit where this bug happens: >> >> commit 4489450f37deafb013b1f0fc00c89f0973fda14a >> Author: Yuan Fu >> Date: Thu Nov 10 15:00:29 2022 -0800 >> >> In end-of-defun, terminate early if no further defun exists >> >> Before this change, end-of-defun calls end-of-defun-function even if >> point is not necessarily at the beginning of a defun (contrary to what >> end-of-defun-function's docstring claims). Now it terminates early >> and doesn't call end-of-defun-function. >> >> * lisp/emacs-lisp/lisp.el (beginning-of-defun-raw): Update docstring >> clarifying the return value. >> (end-of-defun): Terminate early if beginning-of-defun-raw returns nil. > > Yuan, could you please look into this? What I see is that, after 4489450f37deafb013b1f0fc00c89f0973fda14a, defun movement may be subtly broken if beginning-of-defun-function does not return non-nil when it found the beginning of a defun. One of the affected modes is js-mode, but who knows if there are more out there. We could either revert 4489450f37deafb013b1f0fc00c89f0973fda14a, because of the incompatibilities it may cause (Yuan, what is the bug it tries to fix?), or maybe adjust js-mode so that it follows the documentation of beginning-of-defun-function and returns non-nil when it found the beginning of a defun. I've attached a patch that follows this second approach, with some unit tests. It fixes the bug on my side.