GNU bug report logs - #79200
31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79200 <at> debbugs.gnu.org, pipcet <at> protonmail.com, oscarfv <at> telefonica.net,
 monnier <at> iro.umontreal.ca, me <at> pengjiz.com
Subject: Re: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in
 buffer-undo-list
Date: Sat, 09 Aug 2025 16:06:19 +0200

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

>> Cc: 79200 <at> debbugs.gnu.org, oscarfv <at> telefonica.net, monnier <at> iro.umontreal.ca,
>>  me <at> pengjiz.com
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Sat, 09 Aug 2025 15:33:56 +0200
>> 
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> 
>> > Another thought: the format_mode_line_unwind is only called from
>> > display_mode_line (redisplay) and format-mode-line. Why does soemthing
>> > land in the undo list at all? DOes that make sense at all?
>> 
>> jit-lock uses this, which turns undo recording off
>> 
>> subr.el:
>>  5253 (defmacro with-silent-modifications (&rest body)
>>  5254   "Execute BODY, pretending it does not modify the buffer.
>>  5255 This macro is typically used around modifications of
>>  5256 text properties that do not really affect the buffer's content.
>>  5257 If BODY performs real modifications to the buffer's text, other
>>  5258 than cosmetic ones, undo data may become corrupted.
>>  5259 
>>  5260 This macro will run BODY normally, but doesn't count its buffer
>>  5261 modifications as being buffer modifications.  This affects things
>>  5262 like `buffer-modified-p', checking whether the file is locked by
>>  5263 someone else, running buffer modification hooks, and other things
>>  5264 of that nature."
>>  5265   (declare (debug t) (indent 0))
>>  5266   (let ((modified (make-symbol "modified")))
>>  5267     `(let* ((,modified (buffer-modified-p))
>>  5268             (buffer-undo-list t)
>>                    ^^^^^^^^^^^^^^^^^^
>> Maybe there specbinds missing somewhere.
>
> I don't think so.  The additions to buffer-undo-list are because of
> deleting some text, and that cannot be disabled.  The problem we see
> is because there are many-many markers where the text is deleted.

Right, thanks. It goes like this (call graph, incoming):

- record_marker_adjustments undo.c:127
  - record_delete record_delete:187
    + casify_region casify_region:555
    + adjust_after_replace adjust_after_replace:1408
    + replace_range replace_range:1639
    + del_range_2 del_range_2:2030
    + record_change record_change:201

Hm, so binding buffer-undo-list would have no effect.

Previous Next

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