From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty 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: Fri, 28 Jul 2023 19:11:07 +1200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19697"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Orcon Webmail Cc: Adam Porter To: 64911@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 28 09:23:49 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 1qPHpE-0004qK-Al for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jul 2023 09:23:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPHe1-0001qN-Qs; Fri, 28 Jul 2023 03:12: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 1qPHds-0001pj-9u for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 03:12:05 -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 1qPHds-0001YA-1A for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 03:12:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qPHdr-0007dh-Sv for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 03:12:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jul 2023 07:12:03 +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.169052827729224 (code B ref 64911); Fri, 28 Jul 2023 07:12:03 +0000 Original-Received: (at 64911) by debbugs.gnu.org; 28 Jul 2023 07:11:17 +0000 Original-Received: from localhost ([127.0.0.1]:43539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPHd7-0007bI-8M for submit@debbugs.gnu.org; Fri, 28 Jul 2023 03:11:17 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:52675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPHd2-0007b4-Gy for 64911@debbugs.gnu.org; Fri, 28 Jul 2023 03:11:15 -0400 Original-Received: from [10.253.37.70] (port=25611 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1qPHcy-0002wy-2m; Fri, 28 Jul 2023 19:11:09 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 28 Jul 2023 19:11:07 +1200 In-Reply-To: X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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:266233 Archived-At: Tangentially, I can't see any function for obtaining all the markers for a given buffer. I see that this has been raised before as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35536 There's clearly resistance to implementing that, but... it would be very useful for cases like the one I'm looking at. Specifically, the code which is erasing the buffer and then rebuilding it could firstly loop over the buffer markers, store some kind of relevant context for each one and then, after rebuilding the buffer, it could locate the equivalent context in the new buffer text and update each of those markers accordingly. Without a way of querying the buffer's markers it's necessary to just *know* about them and how to access them; and there's no guarantee that new markers won't come into play behind the scenes in future, so it would be useful to be able to access the list without having to have advance information about how and where they were being created. -Phil