Re: Edebug corrupting point in buffers.

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 02, 2022 at 16:00:52 +0200, Eli Zaretskii wrote:
> > Date: Wed, 2 Nov 2022 11:34:37 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > (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.
> > (iv)a Put point into window *scratch*.
> > (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.

> Yes, I see the problem, but setting edebug-save-windows to nil
> eliminates it.  So I think we already have a solution for the rare
> situations where this is an issue.

It remains a perplexing problem for those who stumble into it.  How about
instead of patching the code, adding some documentation clarifying the
problem?

I would propose the following:



diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
index 6a51489d8a..b4f680fe86 100644
--- a/doc/lispref/edebug.texi
+++ b/doc/lispref/edebug.texi
@@ -1019,6 +1019,7 @@ The Outside Context
 @menu
 * Checking Whether to Stop::    When Edebug decides what to do.
 * Edebug Display Update::       When Edebug updates the display.
+* Edebug Buffer Points::        When @code{point} gets corrupted.
 * Edebug Recursive Edit::       When Edebug stops execution.
 @end menu
 
@@ -1100,6 +1101,41 @@ Edebug Display Update
 the cursor shows up in the window.
 @end itemize
 
+@node Edebug Buffer Points
+@subsubsection Edebug's handling of buffer points
+
+When Edebug enters its recursive edit to get a command from the user,
+by default it saves the window points of each window in the selected
+frame (@pxref{Edebug Display Update}).  These are usually, but not
+always, the same as the values of point in the buffers displayed by
+these windows (@pxref{Window Point}).  On leaving the recursive edit,
+these window points get restored, but sometimes buffer points get
+overwritten by them too.
+
+This can be a problem when your program itself sets point in a buffer,
+intending later to use that value of point.  For example, suppose you
+have buffer B displayed in your selected frame, and you step through
+the following Lisp fragment:
+
+@example
+(set-buffer A)
+(set-buffer B)
+(goto-char (point-max))
+(insert "foo")
+(set-buffer A)
+(set-buffer B)
+(insert "bar")
+@end example
+
+@noindent
+``foo'' gets inserted at @code{point-max} as intended, but ``bar''
+sometimes gets wrongly inserted at the window point of the window
+displaying buffer B.
+
+The only known workaround for this problem is to disable
+@code{edebug-save-windows}, for example with the command @kbd{W}
+(@pxref{Edebug Options}).
+
 @node Edebug Recursive Edit
 @subsubsection Edebug Recursive Edit
 
diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi
index a3d1d80408..b07b1e28cd 100644
--- a/doc/lispref/elisp.texi
+++ b/doc/lispref/elisp.texi
@@ -714,6 +714,7 @@ Top
 
 * Checking Whether to Stop::When Edebug decides what to do.
 * Edebug Display Update::   When Edebug updates the display.
+* Edebug Buffer Points::    When @code{point} gets corrupted.
 * Edebug Recursive Edit::   When Edebug stops execution.
 
 Edebug and Macros


-- 
Alan Mackenzie (Nuremberg, Germany).