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 19:57:46 +0000 Message-ID: References: <83iljydh7e.fsf@gnu.org> <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> <83mt99a223.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25459"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 20:58:52 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 1oqgMV-0006Nj-N6 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 20:58:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqgLi-00014s-Lj; Thu, 03 Nov 2022 15:58:02 -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 1oqgLf-000134-6D for emacs-devel@gnu.org; Thu, 03 Nov 2022 15:57:59 -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 1oqgLc-0001FP-KR for emacs-devel@gnu.org; Thu, 03 Nov 2022 15:57:58 -0400 Original-Received: (qmail 38689 invoked by uid 3782); 3 Nov 2022 20:57:48 +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 20:57:47 +0100 Original-Received: (qmail 9416 invoked by uid 1000); 3 Nov 2022 19:57:46 -0000 Content-Disposition: inline In-Reply-To: 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=unavailable 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:299099 Archived-At: Hello, Stefan. On Thu, Nov 03, 2022 at 15:29:38 -0400, Stefan Monnier wrote: > Eli Zaretskii [2022-11-02 16:00:52] wrote: > >> Date: Wed, 2 Nov 2022 11:34:37 +0000 > >> Cc: emacs-devel@gnu.org > >> From: Alan Mackenzie > >> (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. > I wish Someone™ could dig into the problem further and find the source > of the problem and an actual fix, but indeed, this seems like a fair > workaround in the mean time. I think I said something about this earlier on in the thread. The cause seems to be that random bits of software wrongly consider it their business to overwrite the buffer point with a window point. Amongst these bits of software are select-window, set-window-configuration, and our very own edebug-set-buffer-points (triggered by the option edebug-save-displayed-buffer-points). I think there are many more. The solution, were it practicable, would be to have only the command loop or maybe redisplay copying WP to BP, and only just before the window becomes the current place where the user might edit. > Maybe a good short term "fix/workaround" is to change the implementation > of `edebug-save-windows` so that in addition to the windows's info it > also saves&restores the buffer-point of those buffers displayed in the > saved windows. My first patch did something like this. It saved the buffer points of all buffers, then restored it in buffers selected by the user. This patch was rejected (and I think rightly so) for being too clumsy to use. > Stefan -- Alan Mackenzie (Nuremberg, Germany).