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: Edebug corrupting point in buffers; we need buffer-point and set-buffer-point, perhaps. Date: Mon, 31 Oct 2022 11:43:15 +0000 Message-ID: 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="22101"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 31 12:44: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 1opTDO-0005Zy-Kx for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Oct 2022 12:44:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opTCf-0007u6-Az; Mon, 31 Oct 2022 07:43:41 -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 1opTCe-0007tz-A0 for emacs-devel@gnu.org; Mon, 31 Oct 2022 07:43:40 -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 1opTCR-0000vT-LS for emacs-devel@gnu.org; Mon, 31 Oct 2022 07:43:39 -0400 Original-Received: (qmail 98347 invoked by uid 3782); 31 Oct 2022 12:43:16 +0100 Original-Received: from acm.muc.de (p4fe15da4.dip0.t-ipconnect.de [79.225.93.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 31 Oct 2022 12:43:15 +0100 Original-Received: (qmail 4148 invoked by uid 1000); 31 Oct 2022 11:43:15 -0000 Content-Disposition: inline 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:298842 Archived-At: Hello, Emacs. A few weeks ago, I was attempting to edebug a program which itself scanned through a buffer B. That buffer was also displayed in a window (or possibly two windows). Each time the program went into edebug, the point in B got corrupted. Setting edebug-save-displayed-buffer-points didn't help. I now understand what was going wrong. Without edebug-save-displayed-buffer-points, B's point got set to a window point from a random window displaying B, caused by a set-window-configuration call from edebug. With edebug-save-displayed-buffer-points set, the function edebug-get-displayed-buffer points was recording window-points for each displayed window, but after the recursive edit was writing these window-points back into the buffer points. This is surely a bug. At the least, there is a race condition if two windows display the same buffer. In neither of the above scenarios does edebug do anything to restore the buffer points after the recursive edit. This seems to be a bad thing. I propose that edebug should get an option to preserve buffer points, alongside the existing options which preserve window points. One downside of this would be the runtime involved in the set-buffer calls needed to call `point' and `goto-char'. This could make edebug quite sluggish. So, why don't we introduce new functions buffer-point and set-buffer-point? These would enable edebug to record and restore these points economically. Why don't these functions exist already? -- Alan Mackenzie (Nuremberg, Germany).