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: Thu, 03 Nov 2022 16:35:09 -0400 Message-ID: References: <83iljydh7e.fsf@gnu.org> <838rkud9d5.fsf@gnu.org> <83v8nybnuk.fsf@gnu.org> <83pme6bls8.fsf@gnu.org> <83mt99a223.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20666"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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 Thu Nov 03 21:36:21 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 1oqgwm-00058o-SP for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 21:36:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqgvq-0000o0-99; Thu, 03 Nov 2022 16:35:22 -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 1oqgvo-0000nT-LO for emacs-devel@gnu.org; Thu, 03 Nov 2022 16:35:20 -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 1oqgvl-0006yo-Fh; Thu, 03 Nov 2022 16:35:20 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C794280893; Thu, 3 Nov 2022 16:35:12 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5A6458025C; Thu, 3 Nov 2022 16:35:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667507711; bh=49UqCbeJeRzKLbzT9EbBbHRf/nDGrG4tATyOLjy11Wk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FeByRIcHnvGqqyNDbcbfBDLilkPjEyM9WPFxXzOhpRJnkQtOt7HpknbMYjQIUXaNR NtP6t/tqhRMbaJ5uOK1pDaz1kwat2SA/pSdnpz/yMB1eSY/zGory9auvqCWa11ldk4 z3wMQAcJlWuDRq1oYPrDPd9jV68H5xC84WMBVbcfhKWUPRM7VB3MqWQUBWSebtRiWy lKGglHsYrPXwDl84Ab+0p6VAfqpALm4FqE/ucrCtK2MgawIsaQ2c8/GiN9SQrMa7Bb hoqOJ3JynIfOfSgZFQVIavgQx6i+JSVZv2QpJjY/b+UdjhTL6wnlFjv1CIhlWES7Km adTvohK9s7mCg== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 22AFB120FB6; Thu, 3 Nov 2022 16:35:11 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Thu, 3 Nov 2022 19:57:46 +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:299103 Archived-At: >> I wish Someone=E2=84=A2 could dig into the problem further and find the = source >> of the problem and an actual fix, but indeed, this seems like a fair >> workaround in the mean time. > > I think I said something about this earlier on in the thread. The cause > seems to be that random bits of software wrongly consider it their > business to overwrite the buffer point with a window point. > > Amongst these bits of software are select-window, > set-window-configuration, and our very own edebug-set-buffer-points > (triggered by the option edebug-save-displayed-buffer-points). I think > there are many more. This characterization is a bit too vague and open-ended to be actionable, sadly. I was thinking of "the source of the problem" for the specific case you described earlier in the bug-report (i.e. one we can conveniently reproduce). Admittedly, fixing this one case may not fix all cases, but will at least get us closer. >> Maybe a good short term "fix/workaround" is to change the implementation >> of `edebug-save-windows` so that in addition to the windows's info it >> also saves&restores the buffer-point of those buffers displayed in the >> saved windows. > My first patch did something like this. It saved the buffer points of > all buffers, then restored it in buffers selected by the user. This > patch was rejected (and I think rightly so) for being too clumsy to use. I was thinking that by limiting the saved&restored buffer-points to those displayed in the saved windows, we'd make it more "automatic" than your patch. Stefan