Re: Edebug corrupting point in buffers.

[Alan Mackenzie]

Hello, Eli.

On Tue, Nov 01, 2022 at 13:53:09 +0200, Eli Zaretskii wrote:
> > Date: Tue, 1 Nov 2022 11:41:02 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > +If the value is a list of buffer names (recommended), only those
> > > > +buffers will have their buffer points restored.  Otherwise, t means
> > > > +restore all buffers\\=' points, and nil means none.

> > > If we indeed need such an option, why shouldn't it be Edebug's
> > > business to automatically keep point in all buffers that are displayed
> > > in some window?  It doesn't strike me as the best UI to burden the
> > > user with that task.

> > It would be intolerable for users.  Say during an edebug session, the
> > user makes some notes in buffer my-notes.txt.  Execute an instruction,
> > then go back to my-notes.txt.  Point has been "restored" to before the
> > new notes.  That would happen in every buffer.

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

> Maybe I don't understand what your patch does, then.  I thought it was
> supposed to _prevent_ such moves from happening.

In the blank line in test-edebug.el, the patch prevents emacs.README's
buffer-point being set to the window-point of the window in which the
buffer is displayed.

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

> But in any case, I didn't ask _what_ happens, I asked _why_?  IOW, I
> presumed that you understood why Edebug moves point, and asked for a
> detailed description of the code involved and the reason it gets
> executed in this scenario.

OK, here goes!

It's all in the function edebug--display-1, which in the master copy of
edebug.el starts at L2573.  At L2628, e--display-1 calls
edebug-current-windows, which calls current-window-configuration, saving
the configuration in edebug-outside-windows.

The recursive edit takes place at L2730, in which the user types a space
to execute one instruction.  Suppose that was L9 from test-edebug.el (see
above).  The current buffer is now A (*scratch*).

At L2754, the function calls edebug-set-windows which calls
(set-window-configuration edebug-outside-windows).

The program advances one instruction and calls edebug--display-1 again.
It calls .... which calls current-window-configuration, which stores the
window-point of buffer B (emacs.README) which is no longer the current
buffer.

In the recursive edit, the user again types space which advances over
L10.

At L2754 again, ... which calls set-window-configuration.  This time B
was not the current buffer stored by current-window-configuration, so B's
BUFFER-POINT GETS RESTORED TO ITS STORED WINDOW-POINT.  This happens at
src/window.c function Fset_window_configuration at L7270.

This restored point in buffer B is where the second `insert' wrongly
takes effect.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).