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

Previous Next

Full log

Message #36 received at 66218 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66218 <at> debbugs.gnu.org
Subject: Re: bug#66218: 29.1.50; `beginning-of-defun' jumps to wrong
 position in `emacs-lisp-mode'
Date: Sat, 07 Oct 2023 19:39:52 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> Cc: 66218 <at> 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.

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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.