Re: Edebug corrupting point in buffers.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 1 Nov 2022 13:42:03 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > ??? Why would point be restored to the value before the last move of
> > point?  The program you are debugging doesn't affect that buffer with
> > notes, does it?
> 
> Probably not, but it might.  The point is, edebug can't know [*] which
> buffers have been modified by edebug itself, and which have been modified
> by the user.  Some might have been modified by both.
> [*] Without significant enhancement to edebug.

What do you mean by "buffers modified by edebug itself"?  AFAIK,
Edebug doesn't modify any buffers except the one where you are
stepping, where it moves the overlay arrow and point.

> > > With test-edebug.el being
> > > #########################################################################
> > >  1 (defun test-edebug ()
> > >  2   (let ((A "*scratch*") (B "emacs.README"))
> > >  3    (set-buffer A)
> > >  4    (set-buffer B)
> > >  5    (goto-char (point-max))
> > >  6    (insert "(2022-11-01)\n")
> > >  7    ;; B's buffer-point is at point-max.
> > >  8
> > >  9    (set-buffer A)
> > > 10    (set-buffer B)
> > > 11    ;; B's buffer-point is no longer at point-max.
> > > 12   (insert "(2022-11-01)a\n")))
> > > #########################################################################
> > > ,
> > > (i) Emacs -Q.
> > > (ii) On a single frame, arrange buffers *scratch*, test-edebug.el, and
> > >   some other substantial buffer, that I call emacs.README.
> > > (iii) Put point in emacs.README somewhere other than point-max.
> > > (iv) Instrument test-edebug for edebug with C-u C-M-x.
> > > (v) M-: (test-edebug).
> > > (vi) Step through test-edebug using the space key.
> > > (vii) Note that the second text insertion happens where point was in the
> > >   window, not at point-max.  This is the bug.
> 
> > I cannot reproduce this: for me, the insertion is at point-max.  Maybe
> > your recipe description is incomplete?
> 
> Apologies.  I neglected to mention that window-saving (toggled by "W" in
> an edebug session) must be enabled to trigger the bug.  Indeed, I wasn't
> fully aware of this.

If the problem happens only when edebug-save-displayed-buffer-points
is non-nil, then maybe we should step back a notch and ask why you set
that option?  It is nil by default.  What doesn't work for you if you
keep it at its nil value?

AFAIU, this variable exists for some very special situations (which
ones exactly I admit I don't have a clear idea), and it could be that
your use case is not one of them.