From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: gmane.emacs.devel
Subject: Re: Edebug corrupting point in buffers.
Date: Tue, 01 Nov 2022 17:51:45 -0400
Message-ID: <jwvk04e1hsn.fsf-monnier+emacs@gnu.org>
References: <Y2EFztE/GgFF0P3x@ACM> <83iljydh7e.fsf@gnu.org>
 <Y2EiK32B9lxLSFms@ACM> <838rkud9d5.fsf@gnu.org> <Y2FSHvmj2H8a5AS6@ACM>
 <83v8nybnuk.fsf@gnu.org> <Y2FWSoSCQnnY9en1@ACM>
 <83pme6bls8.fsf@gnu.org> <Y2FtQMonpNeR1m1k@ACM>
 <jwv7d0e3235.fsf-monnier+emacs@gnu.org> <Y2GHWybprtVeF0pb@ACM>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="17137"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
To: Alan Mackenzie <acm@muc.de>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 22:52:38 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 1opzBV-0004Ef-Sg
	for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 22:52:38 +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 1opzAv-0000Zk-TZ; Tue, 01 Nov 2022 17:52:01 -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 <monnier@iro.umontreal.ca>)
 id 1opzAt-0000YX-95
 for emacs-devel@gnu.org; Tue, 01 Nov 2022 17:51:59 -0400
Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <monnier@iro.umontreal.ca>)
 id 1opzAr-0007YM-CL; Tue, 01 Nov 2022 17:51:59 -0400
Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0298A1001D4;
 Tue,  1 Nov 2022 17:51:54 -0400 (EDT)
Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 33B3610010D;
 Tue,  1 Nov 2022 17:51:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1667339506;
 bh=zoYkofq94VA+aqhVsHnf0xqtoyxbH9GgywIizB1BYS0=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Mh56/Veq6GB6bGG/ufPohFs9fWunKR6YSSQGxfCyR5isWuiVrsx2T4sDRIWYUy3lL
 n2/yywHcwa1aQ7ayEI8bPzoVi1oFo6AsgrHXb67cF165kttdvYbQ8kQkIugPc/wYpP
 ntNzgtfWUSwHoC4nAQf9d88b2mBqt/09H/2C/Bdsvx0bKfhvLCZ6DKqCG3zavQ/J6k
 w4owC4inPb6QDn+dzyCWWuw01YyGCQSsD8Kl+5dJdSd5zrkNr7GfaMUQOBSzCNDZ1Q
 U0RGmpBA9UlablZFv7Dt4Ll1lRkN2lvyGkETo18IND7hADa18f81JhV7o7jmWXlO5c
 aXkObUTXMYabw==
Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1E18C1205EA;
 Tue,  1 Nov 2022 17:51:46 -0400 (EDT)
In-Reply-To: <Y2GHWybprtVeF0pb@ACM> (Alan Mackenzie's message of "Tue, 1 Nov
 2022 20:53:47 +0000")
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 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:298981
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/298981>

>> > Why does set-window-configuration overwrite the buffer-points?
>> > The window configuration does not contain them.  The code just
>> > assumes that the buffer-point should be set to the window point.
>> > Of course, we have a race condition if a buffer is displayed in
>> > several windows.  So this would appear to be a bug, the root cause
>> > of the bug in this thread.
>
>> This suggests the patch below, right?
>> I note that this only changes the buffer-point for `current-buffer`,
>> not for all the buffers displayed in the window-config, right?
>
> Not quite.  It changes the buffer-point for every buffer except the
> "current buffer".

Really?  My reading of the code:

	      /* As documented in Fcurrent_window_configuration, don't
		 restore the location of point in the buffer which was
		 current when the window configuration was recorded.  */
	      if (!EQ (p->buffer, new_current_buffer)
		  && XBUFFER (p->buffer) == current_buffer)
		Fgoto_char (w->pointm);

is that it's done only for the current buffer and only if it's different
from the "to be current buffer".

Am I missing something?

>> Yup.  We could start by providing some way to tell
>> `set-window-configuration` not to change buffer-points (and use that in
>> Edebug)?  This way we fix the problem for Edebug without risking
>> changes elsewhere?
> An &optional parameter, you mean?  I'd thought of that, but it feels
> ugly.

Agreed.  Especially since I get the feeling that it's just a plain bug.

That piece of code dates back to the initial revision of window.c back
in 1991, tho.  That function had some serious bugs in the handling of
buffer points which stayed unnoticed for years (I remember the one
I fixed with in 2005 with e67a1dea3e622d61024b2dc17c36831d048bb271), so
I wouldn't be surprised that this one is also a mistake.

> I've tried it, and the patch doesn't fix the bug.  :-(

Why didn't you say so at the beginning of your message?
Now I look like fool!  :-)


        Stefan