Re: Edebug corrupting point in buffers.

[Alan Mackenzie]

Hello, Eli.

On Tue, Nov 01, 2022 at 16:42:30 +0200, Eli Zaretskii wrote:
> > 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.

Sorry, can we pretend I didn't write that last paragraph, please?  It's
nonsense.

Going back to your question three paragraphs ago, which I haven't
answered yet, point in the notes buffer would get restored by the window
configuration stuff we're discussing below.  At least it would if it's
displayed in the selected frame.

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

It is t by default, and has been since Richard S. created or amended the
declaration in 1997.  It frequently annoys me when I go into edebug (but
not enough for me actually to customise it to nil).

> What doesn't work for you if you keep it at its nil value?

Before I got into the habit of typing W to set it to nil, I seem to
remember that sometimes my .el buffer would scroll back to its previous
position when I typed (edebug's) space, sometimes it wouldn't.  I never
worked out why.

Might you have customised it to nil in your own configuration?

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

As I say, I just find it annoying.  But t is the default value for it,
for reasons probably long lost.

-- 
Alan Mackenzie (Nuremberg, Germany).