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: Tue, 01 Nov 2022 16:42:30 +0200 Message-ID: <838rkud9d5.fsf@gnu.org> References: <83wn8fcgvd.fsf@gnu.org> <83iljydh7e.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15075"; 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 Tue Nov 01 18:21:26 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 1opux3-0003g3-Jd for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 18:21:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opsTW-0004Mo-OB; Tue, 01 Nov 2022 10:42:46 -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 1opsTU-0004MV-G4 for emacs-devel@gnu.org; Tue, 01 Nov 2022 10:42:44 -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 1opsTT-0005Yh-FD; Tue, 01 Nov 2022 10:42:43 -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=9/MG/BNmChfeUrOu9TQABldBysjUT4Wpm6gjbAPmZz8=; b=h87fvWENfPGq CdWSkHL8sEem06LI4ga18eCD9vzyD0zuKT/3T0kwvo68yHggEPCoCHvxoywVasagwzu9oU0eGn25b fTFB8E6mna0P9WNg2MPnpNDBGrsuT8nm3XSosdVuZ+MfDDOANrJzt2sunXSIYzGCHR5k9DbJlfLfb ai4cBQU1Gk9z0VD1uJ16cny4nAze5tK2oDC/8AS3La42yoISJqFHP4NDiD1lv1mRmtNtOBGMB5Um6 7tr5YSNEcbpNohXsvNKZB84mHP1SM1EsdTIJsDBg9pomQuY8Jv28fDbNiEIZ4I4nLZGIHS3IYpcny zB0S0N7Y7ioOs9ALD9S9cw==; 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 1opsTS-0001e6-Kd; Tue, 01 Nov 2022 10:42:42 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 1 Nov 2022 13:42:03 +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:298951 Archived-At: > Date: Tue, 1 Nov 2022 13:42:03 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > ??? Why would point be restored to the value before the last move of > > point? The program you are debugging doesn't affect that buffer with > > notes, does it? > > Probably not, but it might. The point is, edebug can't know [*] which > buffers have been modified by edebug itself, and which have been modified > by the user. Some might have been modified by both. > [*] Without significant enhancement to edebug. What do you mean by "buffers modified by edebug itself"? AFAIK, Edebug doesn't modify any buffers except the one where you are stepping, where it moves the overlay arrow and point. > > > With test-edebug.el being > > > ######################################################################### > > > 1 (defun test-edebug () > > > 2 (let ((A "*scratch*") (B "emacs.README")) > > > 3 (set-buffer A) > > > 4 (set-buffer B) > > > 5 (goto-char (point-max)) > > > 6 (insert "(2022-11-01)\n") > > > 7 ;; B's buffer-point is at point-max. > > > 8 > > > 9 (set-buffer A) > > > 10 (set-buffer B) > > > 11 ;; B's buffer-point is no longer at point-max. > > > 12 (insert "(2022-11-01)a\n"))) > > > ######################################################################### > > > , > > > (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. > > > (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. > > > I cannot reproduce this: for me, the insertion is at point-max. Maybe > > your recipe description is incomplete? > > Apologies. I neglected to mention that window-saving (toggled by "W" in > an edebug session) must be enabled to trigger the bug. Indeed, I wasn't > fully aware of this. If the problem happens only when edebug-save-displayed-buffer-points is non-nil, then maybe we should step back a notch and ask why you set that option? It is nil by default. What doesn't work for you if you keep it at its nil value? AFAIU, this variable exists for some very special situations (which ones exactly I admit I don't have a clear idea), and it could be that your use case is not one of them.