From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Edebug corrupting point in buffers. Date: Thu, 03 Nov 2022 15:29:57 +0200 Message-ID: <83wn8c6u96.fsf@gnu.org> References: <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> <83mt99a223.fsf@gnu.org> <83cza59tvg.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39553"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 14:31:28 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 1oqaJc-000A3Q-9N for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 14:31:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqaIo-0004Zz-Sy; Thu, 03 Nov 2022 09:30: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 1oqaIm-0004Vq-9N for emacs-devel@gnu.org; Thu, 03 Nov 2022 09:30:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqaIl-0000Yw-Bm; Thu, 03 Nov 2022 09:30:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dMJx7/SZ+9PDzLRnTaxukEcQrYPa16WzhtI7CdfB5Sc=; b=jnEQfMrn7i2T upNLujaHuq2s0Cv0sDmJdZC2c70FXHw31Ptltklvg6E5mLK/SHAHEiyYn4Kkn1VxrXEOWCna/cL8n 9cZ8Qg/Cz7STj8hynHSXMNM3dns68TkjDGsI4sRmohQl/Uba+vV7fqo0pLcCivpR8MFN7XHsAim+n xwVm5Gq7xukKCg0F4VCxck1iBBKC3ThY9Iea+le2UTgM74HpYHkJYMQItdvbSG00pIPFkTFU6yECY 1FCy/JMdNr8L4D+7OooEZXN3JZwt/baDcf2VJGbIjC+bZeoLQjLuv+cyej3nXjNb3cREl2WIgW5rJ jk26TLtQ5mpdNuYQ+j2Tdg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqaIG-0007gS-Jr; Thu, 03 Nov 2022 09:30:27 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 3 Nov 2022 11:32:29 +0000) 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:299072 Archived-At: > Date: Thu, 3 Nov 2022 11:32:29 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > +@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}. > + The node you added is very short, barely a dozen lines. It makes little sense to have it separate from where edebug-save-windows is described. So I think you should move it there. The location of the node inside the manual's hierarchy is much less important than to have the information pertaining to edebug-save-windows in a single place, because no one reads the ELisp reference manual in its entirety. The only thing we need to facilitate people finding this place is add good index entries there. Thanks.