From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Edebug corrupting point in buffers. Date: Thu, 3 Nov 2022 11:32:29 +0000 Message-ID: References: <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> <83mt99a223.fsf@gnu.org> <83cza59tvg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34166"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 12:33:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oqYTT-0008gv-Ea for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 12:33:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqYSc-00086v-QG; Thu, 03 Nov 2022 07:32:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqYSZ-00083T-Ih for emacs-devel@gnu.org; Thu, 03 Nov 2022 07:32:35 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqYSW-0006Bq-Oj for emacs-devel@gnu.org; Thu, 03 Nov 2022 07:32:34 -0400 Original-Received: (qmail 93652 invoked by uid 3782); 3 Nov 2022 12:32:30 +0100 Original-Received: from acm.muc.de (p4fe15d9a.dip0.t-ipconnect.de [79.225.93.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Nov 2022 12:32:29 +0100 Original-Received: (qmail 6345 invoked by uid 1000); 3 Nov 2022 11:32:29 -0000 Content-Disposition: inline In-Reply-To: <83cza59tvg.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299070 Archived-At: 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 > > > 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).