bug#66218: 29.1.50; `beginning-of-defun' jumps to wrong position in `emacs-lisp-mode'

[Eli Zaretskii]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 66218@debbugs.gnu.org
> Date: Sat, 07 Oct 2023 19:39:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> >> Cc: 66218@debbugs.gnu.org
> >> Date: Sat, 07 Oct 2023 17:47:19 +0200
> 
> > I'm surprised, to say the least, that such a simple bug needs such a
> > complex reproducer, and any deviation from it fails the recipe.  I
> > think we must understand why.
> 
> As soon as you find the file and it's displayed in a window, a lot of
> things happen even in an "emacs -Q" that set syntax properties in the
> buffer.  With these syntax properties already being set, the bug won't
> reproduce.

Then I think we have no reason to rush with fixing this on emacs-29.

> But here is an interactive-only reproducer (which comes close to my
> truth, btw, I don't use eldoc-mode or show-paren-mode):
> 
> emacs -Q
> 
> C-- M-x global-font-lock-mode RET
> C-- M-x global-eldoc-mode RET
> C-- M-x show-paren-mode RET
> C-x C-f lisp/net/shr.el RET
> M-x goto-char RET 70719 RET
> C-M-a
> 
> Ends up on point=68645 of 91908 for me.

Yes.

> > And if it turns out that the problem is so hard to reproduce, maybe we
> > don't have to fix it on emacs-29.
> 
> Even if the patch is so innocent as adding a `save-match-data' in the
> right place?

No patch is "innocent" in Emacs, believe me.  But yes, even so.