GNU bug report logs - #73548
31.0.50; track-changes--error-log

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 73548 <at> debbugs.gnu.org
Subject: Re: bug#73548: 31.0.50; track-changes--error-log
Date: Thu, 03 Oct 2024 11:15:10 -0400

Hi Gerd,

> This is a warning I got today while editing a C file. No idea how to
> reproduce, I'm afraid. This is master on a terminal frame.
>
>    ■  Warning (emacs): Missing/incorrect calls to ‘before/after-change-functions’!!
>   Details logged to ‘track-changes--error-log’
>
> track-changes--error-log is a variable defined in ‘track-changes.el’.
>
> Its value is shown below.
>
> List of errors encountered.
> Each element is a triplet (BUFFER-NAME BACKTRACE RECENT-KEYS).
>
> Value:
> (("frame.h" #1=(unexpected-after 47748 47748 1)
>   ((t track-changes--recover-from-error (#1#) nil)
>    (t track-changes--after (47748 47748 1) nil)
>    (t delete-char (-1 nil) nil) (t delete-backward-char (1 nil) nil)
>    (t backward-delete-char-untabify (1) nil)
>    (t c-electric-backspace (nil) nil)
>    (t funcall-interactively (c-electric-backspace nil) nil)
>    (t call-interactively (c-electric-backspace nil nil) nil)
>    (t command-execute (c-electric-backspace) nil))
>   [86 (nil . self-insert-command) 73 (nil . self-insert-command) 83
>       (nil . self-insert-command) 73 (nil . self-insert-command) 66
>       (nil . self-insert-command) 76 (nil . self-insert-command) 69
>       (nil . self-insert-command) 32 (nil . self-insert-command) 40
>       (nil . c-electric-paren) 127 (nil . c-electric-backspace)]))

Hmm... the recent-keys only include "harmless" commands which definitely
should not trigger those "unexpected-after" problems.

The problem that track-changes reports here is that the call to
`after-change-functions` specified a region that's (apparently) outside
the area specified by the previous `before-change-functions`.
Since this is within `delete-char` (according to the backtrace), it's
very weird: `delete-char` is a very basic case where such an error
should have been noticed many years ago.

Do you remember if there might have been other buffer changes during
this `delete-char` e.g. because of some other package hooked (directly
or not) into one of the `*-change-functions`?


        Stefan

Previous Next

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