Re: Edebug corrupting point in buffers.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Nov 02, 2022 at 18:57:39 +0200, Eli Zaretskii wrote:
> > Date: Wed, 2 Nov 2022 16:18:24 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> Fine by me, but...

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

> ...please document this in the same place where the variables we
> discussed are described.  It is not a good idea from the didactic POV
> to have this described separately.

The place I put it, under "The Outside Context" has as its purpose
"Edebug tries to be transparent to the program you are debugging, but it
does not succeed completely. ..... This section explains precisely what
context Edebug restores, and how Edebug fails to be completely
transparent."

The current phenomenon fits precisely into that category.  Surely we need
to describe it there, otherwise the section will be incomplete.

I envisage the main purpose of this new documentation is not for somebody
calmly reading through the manual learning about edebug-save-windows.
Rather it's for somebody in a highly emotional state, who's just had
edebug corrupt his buffers due to an apparent bug in edebug.  I think
this user is more likely to find the new doc quickly where my patch puts
it.

On the other hand, as you say, we do need a description in the list item
for edebug-save-windows in "Edebug Options" 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

> I very much doubt that showing this example will help.  It just
> muddies the water, b y forcing users to try to understand what the
> example does, which is completely irrelevant to what we want to
> convey.

OK, I'll take it out, together with the description.  Instead I'll insert
something vague about switching buffers and moving point in them.

> Just say that if point gets reset in non-selected windows during
> Edebug stepping, users should try customizing that variable.

I'll do that.


Here's an amended patch, somewhat shorter than yesterday's:



diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
index 6a51489d8a..aab8db989a 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,22 @@ 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 occasionally be a problem when your program switches buffers
+and sets point in them.  The recommended workaround is to disable the
+option @code{edebug-save-windows}, for example with the command
+@kbd{W} (@pxref{Edebug Options}).
+
 @node Edebug Recursive Edit
 @subsubsection Edebug Recursive Edit
 
@@ -1657,6 +1674,11 @@ Edebug Options
 what happens to the window configurations, it is better to set this
 variable to @code{nil}.
 
+Saving the window configuration can sometimes corrupt the values of
+point in buffers displayed by these windows.  If this happens, you are
+recommended to set @code{edebug-save-windos} to @code{nil}.
+@xref{Edebug Buffer Points}.
+
 If the value is a list, only the listed windows are saved and
 restored.
 
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).