From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer Date: Sat, 29 Jul 2023 10:08:17 +0200 Message-ID: <06f426ed-31e4-befe-f4a9-9b1ba70de1bd@gmx.at> References: <83sf98jyc7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7434"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, 64911@debbugs.gnu.org To: Eli Zaretskii , Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 29 10:10:36 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qPf23-0001nE-WB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jul 2023 10:10:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPf0c-0000x1-7L; Sat, 29 Jul 2023 04:09:06 -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 1qPf0Z-0000wa-PG for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 04:09:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qPf0Y-0005r8-Ij for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 04:09:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qPf0Y-0002GI-01 for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 04:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jul 2023 08:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64911 X-GNU-PR-Package: emacs Original-Received: via spool by 64911-submit@debbugs.gnu.org id=B64911.16906181188664 (code B ref 64911); Sat, 29 Jul 2023 08:09:01 +0000 Original-Received: (at 64911) by debbugs.gnu.org; 29 Jul 2023 08:08:38 +0000 Original-Received: from localhost ([127.0.0.1]:46405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPf0A-0002Fg-7X for submit@debbugs.gnu.org; Sat, 29 Jul 2023 04:08:38 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:34561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPf07-0002FR-FD for 64911@debbugs.gnu.org; Sat, 29 Jul 2023 04:08:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1690618098; x=1691222898; i=rudalics@gmx.at; bh=ZpoUXX01ab7Je2Is5vXZAhftllYM3rqyCBm7sD92UUI=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=MtLaSOMpMtoMbv/xP0r6BqeevXz+4LtSc+U7YIt05ky42xirycrzXosN4J5J59qnarYk2xI rtCEvA18zPr8MHaBFlzJJaRMVvE/qjZR7TFHaXffXl4ynKsVpuolAZRMCZ8rVYIGtqBLojcaZ mEJBj9FwXSJ2XuXk4WrS7ACCPjJyu30lcn0/D+lRRH4bK9NSB2xHTehFeLwGTnF4Tr0//fIOg uhzMw/V0m4u+abE8UBSypm676WmXY43eu40oUGrNnzRaxsqLk33d6KbGMvlqfoI/7NNhHd1c+ EBE7f7AEEkxhiqCkDbrPGm0W2k+4KGLHCTc5S3x+pUarSCDstDww== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([46.125.249.21]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MwQT9-1pXpxP2x3l-00sNrJ; Sat, 29 Jul 2023 10:08:18 +0200 Content-Language: en-US In-Reply-To: <83sf98jyc7.fsf@gnu.org> X-Provags-ID: V03:K1:cV4+nua+7v/B8KZ5w4267G61wCuB2FNfUd9iy86N/qaoHYNU1X6 2oPj1cP/ImjLJ3GgPTQ3aZ+mBeofl2PzkVNR5a6+5q4XebRTzQtUz+pXtAflhb3jelShuj+ fvyCFkBYPlszNkpRZb/90S4DCoiqV9EEHfvm7215981K32p07tn2GdLW3g9MZujAogPXtp3 HDWMd07TyY2P1Lu5O+Vow== UI-OutboundReport: notjunk:1;M01:P0:k5+6ImQYg2c=;VO1p5RbtjKjbwElA/LkBTqHLmO/ MFnvYWAXygqq2gjIOP1YKNCJjO6nogiguB/vJQaOsd8xtV/HnbEaE9+fM8+Y2uU9hZJG5O7dT Gbzxw+0YvtP+HSuws5ms2biRlSqH3XecLE7Y3f52gwfVZaRklXno1rP+ttuHPr4f0WpbQNdxL /Sw573Qp+0DSLRUXOdWn3Fejd4dbMsqLJdHjEv7wC8BopJzoY36fl6gsS5KKSwpSuKCoPg93z ouPovbtClZEk5nK6b6JplrTRSFbFQ7qVn1hHx2XuyREN74nBiqOa9rlobJN7cXMBhP8tGEHcl fzZkJFKT6OHqMMoZmqTi+qEEV/lIk7q5ByTVCcW6tJpFqHKRbO0E1i8xA+VvyzZHtTNxCyeQT k6wUfKKPInwzvbSwivnrGpb3UxFQknJP5OmR9relRBeuF53N4jx3T+R8C4MaQb0Ze42WDvPKY bQi5l3SGE3OvjxiT2k5iX0QveAZz/EXdsEWWwhPvewsGvZOfQMloyIuilKzuEFcPaDy6sYK/D dPPzkmysPr1132TM45SFZz0+pdL+nno3PCTC61php/7QXqurnH+gUT16dwLnAwuHQi9QxYcAh igYiPqUvzG02TXuxj4sqKF+o9w1LzbCqn8zq9D6+G4cX9JivxaE2JcN3+jsDhhwyjHfjLv4JI hBVkUCNmM1zL8hcbYjXKMeFIehKhmNDZV+BT25LV/rbXTO4SED3whKXczKoL1vvhGW8ndaYE+ 5wi1uBW7iPsrZyvE6B10lQTNhs8xiR/5DXSo7092SQPt/XLltp2DniJlw8n3eWq7osutbMg/ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266315 Archived-At: >> In practice this is a problem because the position stored in the >> `window-prev-buffers' data is a marker (or at least that is the case >> in the scenario I am dealing with), and the buffer in question is >> periodically erased and regenerated. Erasing the buffer causes all >> its markers to be moved to position 1, so the end result is that the >> user loses their place. (The buffer contents are rebuilt, but the >> new content is typically similar if not identical to the old content, >> and so maintaining the original position is desirable). > > This sounds like quite a unique use case to justify a global behavior > change of 2 commands. Can't you achieve what you need by other means? > Stashing the value of point or window-point somewhere and then > restoring it doesn't sound too complicated to me. > > Adding martin, in case he has comments and suggestions. The only idea I have is to handle the "erased and regenerated" case by invalidating the point markers. IIUC this means that we have to first identify the "erased and regenerated" case in 'after-change-functions' and then use 'window-prev-buffers' to update the POS field of all entries for that buffer in every window it has shown it. We will miss occurrences in saved window configurations if the associated window is not live. martin