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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4