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 13:53:09 +0200 Message-ID: <83iljydh7e.fsf@gnu.org> References: <83wn8fcgvd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3300"; 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+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 12:54:09 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 1oppqK-0000YF-1i for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 12:54:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opppd-0005k9-Cy; Tue, 01 Nov 2022 07:53:25 -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 1opppc-0005k1-Iv for emacs-devel@gnu.org; Tue, 01 Nov 2022 07:53:24 -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 1opppb-0007YA-Qf; Tue, 01 Nov 2022 07:53:23 -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=Mf9r0HSMq9ipkiZRqk+lc3prp+tRJy6OkH3Q2kJD/eQ=; b=BLo1ojEO+bKK Olo49iWShD219HfDAa5p1GqYfJbqIlvDiREFAdgZtHY6O5Kgei/OrEztpveSNktH9iGI6EBIvlu+2 bbq/NQOGb2N55af8IfugO63zxg7qBIccyhom442AcM/Ky78dbMjVuj1L/jWiTui8IMQ7ZMBqSAJVA qNYER4lxyk7HSoQxbNKgJMZAiTC/fJsJm5g8zD7XAL2oUvlrY0xre56mUKbIrcYXPxT4cnXA5frlG 2/lgb37v4McZL0cTXpu7rPu7lVuh4PIHU5YcL35Q1dNmAsV+aUyK2jW5S7X5uQk0//BGJVGeVpHMb dBjkwGDbC9tMejQYLpQMIw==; 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 1opppb-0003Ro-8X; Tue, 01 Nov 2022 07:53:23 -0400 In-Reply-To: (message from Alan Mackenzie on Tue, 1 Nov 2022 11:41:02 +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+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298930 Archived-At: > Date: Tue, 1 Nov 2022 11:41:02 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > > +If the value is a list of buffer names (recommended), only those > > > +buffers will have their buffer points restored. Otherwise, t means > > > +restore all buffers\\=' points, and nil means none. > > > If we indeed need such an option, why shouldn't it be Edebug's > > business to automatically keep point in all buffers that are displayed > > in some window? It doesn't strike me as the best UI to burden the > > user with that task. > > It would be intolerable for users. Say during an edebug session, the > user makes some notes in buffer my-notes.txt. Execute an instruction, > then go back to my-notes.txt. Point has been "restored" to before the > new notes. That would happen in every buffer. ??? 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? Maybe I don't understand what your patch does, then. I thought it was supposed to _prevent_ such moves from happening. > With test-edebug.el being > ######################################################################### > (defun test-edebug () > (let ((A "*scratch*") (B "emacs.README")) > (set-buffer A) > (set-buffer B) > (goto-char (point-max)) > (insert "(2022-11-01)\n") > ;; B's buffer-point is at point-max. > > (set-buffer A) > (set-buffer B) > ;; B's buffer-point is no longer at point-max. > (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? But in any case, I didn't ask _what_ happens, I asked _why_? IOW, I presumed that you understood why Edebug moves point, and asked for a detailed description of the code involved and the reason it gets executed in this scenario. Thanks.