GNU bug report logs - #78042
31.0.50; Improper sequence of `before/after-change-functions` calls

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: monnier <at> iro.umontreal.ca, 78042 <at> debbugs.gnu.org
Subject: Re: bug#78042: 31.0.50;
 Improper sequence of `before/after-change-functions` calls
Date: Fri, 25 Apr 2025 09:08:53 +0300

> Cc: monnier <at> iro.umontreal.ca
> Date: Thu, 24 Apr 2025 11:38:59 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Package: Emacs
> Version: 31.0.50
> 
> 
> I just found another case where we break our promises w.r.t
> `before/after-change-functions`:
> 
>     src/emacs -Q src/regexp-emacs.c
>     M-: (decode-coding-region 123 (point-max) 'windows-1252) RET
> 
> [ The details of the file and buffer positions don't really
>   matter, AFAIK.  ]
> 
> I first get a run of `before-change-functions` for 123...point-max, as
> expected at the beginning and a run of `after-change-functions` for
> 123...point-max, as expected at the end, but between the two I get
> another run of `before-change-functions` for 123..16497:
> 
>     #0  signal_before_change
>         (start_int=start_int <at> entry=123, end_int=end_int <at> entry=16497, preserve_ptr=preserve_ptr <at> entry=0x0) at insdel.c:2157
>     #1  0x0000555555702c3a in prepare_to_modify_buffer_1
>         (start=start <at> entry=123, end=end <at> entry=16497, preserve_ptr=preserve_ptr <at> entry=0x0) at insdel.c:2024
>     #2  0x00005555557c9f36 in modify_text_properties (buffer=MISSING, 
>         buffer <at> entry=XIL(0x555555dfac0d), start=MISSING, end=MISSING) at textprop.c:85
>     #3  0x00005555557cb5cc in add_text_properties_1
>         (start=make_fixnum(123), end=make_fixnum(16497), properties=XIL(0x7fffffffce33), object=XIL(0x555555dfac0d), set_type=set_type <at> entry=TEXT_PROPERTY_REPLACE, destructive=destructive <at> entry=true) at textprop.c:1236
>     #4  0x00005555557cb9b8 in Fadd_text_properties (start=MISSING, 
>         start <at> entry=make_fixnum(123), end=MISSING, 
>         end <at> entry=make_fixnum(16497), properties=MISSING, object=MISSING, 
>         object <at> entry=XIL(0x555555dfac0d)) at textprop.c:1308
>     #5  0x00005555557cba12 in Fput_text_property
>         (start=make_fixnum(123), end=end <at> entry=make_fixnum(16497), property=MISSING, 
>         property <at> entry=XIL(0x55b0), value=MISSING, 
>         value <at> entry=XIL(0x2aaa9984e428), object=XIL(0x555555dfac0d))
>         at textprop.c:1326
>     #6  0x0000555555644852 in produce_charset
>         (coding=coding <at> entry=0x7fffffffd080, charbuf=charbuf <at> entry=0x555556a7ef88, pos=pos <at> entry=16497) at coding.c:7277
>     #7  0x00005555556448e8 in produce_annotation
>         (coding=coding <at> entry=0x7fffffffd080, pos=16497, pos <at> entry=123)
>         at coding.c:7320
>     #8  0x000055555564578f in decode_coding (coding=coding <at> entry=0x7fffffffd080)
>         at coding.c:7421
>     #9  0x000055555564cc32 in decode_coding_object
>         (coding=coding <at> entry=0x7fffffffd080, src_object=src_object <at> entry=XIL(0x555555dfac0d), from=from <at> entry=123, from_byte=from_byte <at> entry=123, to=to <at> entry=161558, to_byte=to_byte <at> entry=161558, dst_object=XIL(0x555555dfac0d))
>         at coding.c:8183
>     #10 0x000055555564e1c7 in code_convert_region
>         (start=make_fixnum(123), end=make_fixnum(161558), coding_system=XIL(0x2aaa9984e428), dst_object=XIL(0x555555dfac0d), encodep=encodep <at> entry=false, norecord=norecord <at> entry=false) at coding.c:9510
> 
> There's probably also a corresponding run of `after-change-functions`,
> I haven't checked, but the problem is that the "final run of
> `after-change-functions` for 123...point-max is now "invalid" in the
> sense that it modifies a range of the buffer beyond the last run of
> `before-change-functions`, contrary to what we promise.

Sorry, I don't think I understand the problem.  Is the problem that we
have "nested" notifications, whereby you have

  before-change-functions A1 B1
  before-change-functions A2 B2
  after-change-functions  A2 B2
  after-change-functions  A1 B1

IOW, _any_ situation where we have nested pairs of notifications is
"breaking our promise"?  If so, how can that be avoided in principle
in Emacs, given its recursive nature, except by some mechanism which
collects all the notifications and rearranges them to "keep our
promise"?

Or what am I missing?

Previous Next

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