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 17:51:45 -0400 Message-ID: References: <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="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 , 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 22:52:38 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 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 ) 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 ) 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 ) 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: (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." 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:298981 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? > > 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