Re: Edebug corrupting point in buffers.

[Eli Zaretskii <eliz@gnu.org>]

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

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

> With test-edebug.el being
> #########################################################################
> (defun test-edebug ()
>   (let ((A "*scratch*") (B "emacs.README"))
>     (set-buffer A)
>     (set-buffer B)
>     (goto-char (point-max))
>     (insert "(2022-11-01)\n")
>     ;; B's buffer-point is at point-max.
> 
>     (set-buffer A)
>     (set-buffer B)
>     ;; B's buffer-point is no longer at point-max.
>     (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?

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.

Thanks.