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: Re: Edebug corrupting point in buffers. Date: Wed, 2 Nov 2022 10:40:59 +0000 Message-ID: References: <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> 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="1817"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 02 11:42:00 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 1oqBC4-0000HY-7y for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Nov 2022 11:42:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqBBK-0007Bl-Lx; Wed, 02 Nov 2022 06:41:14 -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 1oqBBI-000791-H4 for emacs-devel@gnu.org; Wed, 02 Nov 2022 06:41:12 -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 1oqBBB-0000is-9i for emacs-devel@gnu.org; Wed, 02 Nov 2022 06:41:09 -0400 Original-Received: (qmail 8555 invoked by uid 3782); 2 Nov 2022 11:41:01 +0100 Original-Received: from acm.muc.de (p4fe15d2a.dip0.t-ipconnect.de [79.225.93.42]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 02 Nov 2022 11:41:00 +0100 Original-Received: (qmail 4606 invoked by uid 1000); 2 Nov 2022 10:40:59 -0000 Content-Disposition: inline In-Reply-To: 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=unavailable 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:299000 Archived-At: Hello, Stefan. On Tue, Nov 01, 2022 at 17:51:45 -0400, Stefan Monnier wrote: > >> > 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? Hmm. I spent a great deal of yesterday asserting false things, then apologising for them. The above was the last such false thing, for which I also apologise. I think I was influenced by the doc string of current-window-configuration, which seems to imply what I wrote above. > >> 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! :-) The fundamental problem is a conceptual one:- so many bits of code wrongly take the liberty of writing to buffer point when they have no business doing so. The only code which should transfer window point to buffer point is the command loop (or maybe redisplay) when the window is about to become the one that the user will edit in. Or something like that. There's clearly been a lot of confusion about window/buffer point over the decades which shows in the number of places such changes in buffer point occur, and the bugs which have sometimes resulted, like the one you cite above. However, even I can see that it is impracticable to try to fix this now. > Stefan -- Alan Mackenzie (Nuremberg, Germany).