From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Alan Mackenzie <acm@muc.de>
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: <Y1+00x9hKKFpAVO6@ACM>
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: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	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 <emacs-devel-bounces@gnu.org>)
	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 <acm@muc.de>) 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 <acm@muc.de>) 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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Original-Sender: "Emacs-devel" <emacs-devel-bounces@gnu.org>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:298842
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/298842>

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).