From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Edebug corrupting point in buffers. Date: Tue, 01 Nov 2022 15:47:45 -0400 Message-ID: References: <83wn8fcgvd.fsf@gnu.org> <83iljydh7e.fsf@gnu.org> <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1769"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 20:49: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 1opxG1-0000H4-1H for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 20:49:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opxFD-0004Zm-Ir; Tue, 01 Nov 2022 15:48:19 -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 1opxEn-0004R5-JR for emacs-devel@gnu.org; Tue, 01 Nov 2022 15:48:06 -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 ) id 1opxEl-0002pX-3M; Tue, 01 Nov 2022 15:47:53 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E936100189; Tue, 1 Nov 2022 15:47:48 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 451B510010C; Tue, 1 Nov 2022 15:47:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667332066; bh=RlPfwCPN6on9Uca7MS0VPxxIQqYUfZdX46TZ6S9pGYU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=a2kBUpGaxME8k6epQC39dIIr7zHwvMggnOJeBXSg6A8xZGujcCaw2eTTYJkListeT JVkvaghEgmIZxVmf4iykEOsFyOsDT7XbCeGLBif7gWeYjRwfAhxMfVK4nQvJ3a9XLE Akwfogrc8PxqKtmqIvzuSAWba1ZT/lpvmVsvQ5H/zALqhonrN1bT8cWoOXXZ86Lnfy k8CBGVZ8funBqY1pytSKI3QEMnxIOAXpRQHuQWI0l9lDan7wcnrluegz8Jra5Wr9Qg 9gJobTNqOlK95Lt6Jyyaz/84vtWFTTvyNw+MBZO6ApZKZ4vjAgYMvPIKp7Eu5U7ntJ CwleNLWReuk5g== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1E5DE121032; Tue, 1 Nov 2022 15:47:46 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Tue, 1 Nov 2022 19:02:24 +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." 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:298976 Archived-At: > 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? There's still a "race condition", of course. > Maybe set-window-configuration should be amended not to write the > buffer-points? That might cause problems in other areas, though. The > window configuration is one of the few areas where the documentation is > poor enough that you need to read the C source to find out what it's > really doing. 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? We can try and run out own Emacs with the patch installed, to see if we notice any regression. If we do, that might help us understand what we should do. If we don't, maybe it's hint that it was really just a bug. Stefan diff --git a/src/window.c b/src/window.c index b858d145415..382d3cbdc6a 100644 --- a/src/window.c +++ b/src/window.c @@ -7270,12 +7270,6 @@ DEFUN ("set-window-configuration", Fset_window_configuration, set_marker_restricted (w->start, p->start, w->contents); set_marker_restricted (w->pointm, p->pointm, w->contents); set_marker_restricted (w->old_pointm, p->old_pointm, w->contents); - /* 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); } else if (BUFFERP (w->contents) && BUFFER_LIVE_P (XBUFFER (w->contents))) /* Keep window's old buffer; make sure the markers are real. */