From unknown Thu Sep 18 18:06:13 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jul 2023 05:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 64911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 64911@debbugs.gnu.org Cc: Adam Porter X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.169052190417878 (code B ref -1); Fri, 28 Jul 2023 05:26:01 +0000 Received: (at submit) by debbugs.gnu.org; 28 Jul 2023 05:25:04 +0000 Received: from localhost ([127.0.0.1]:43479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPFyJ-0004eG-J0 for submit@debbugs.gnu.org; Fri, 28 Jul 2023 01:25:04 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPFyE-0004de-Um for submit@debbugs.gnu.org; Fri, 28 Jul 2023 01:25:02 -0400 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 1qPFy8-00019X-K7 for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 01:24:52 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPFy6-0000Yx-HU for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 01:24:52 -0400 Received: from [10.253.37.70] (port=29455 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1qPFxs-0004F2-Fc; Fri, 28 Jul 2023 17:24:41 +1200 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 17:24:36 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Jul 2023 17:24:36 +1200 From: Phil Sainty Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.43; envelope-from=psainty@orcon.net.nz; helo=smtp-2.orcon.net.nz X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) The `switch-to-buffer-preserve-window-point' variable determines whether the (BUFFER WINDOW-START POS) data returned by `window-prev-buffers' will be used by `switch-to-buffer' to set the window's start and point positions. I think this variable should additionally be respected by both: - `switch-to-prev-buffer' - `switch-to-next-buffer' (If not others? These are the cases I'm presently aware of.) Each of the latter functions has two calls like this: (set-window-buffer-start-and-point window new-buffer (nth 1 entry) (nth 2 entry)) where `entry' comes from a call to `window-prev-buffers', and the `switch-to-buffer-preserve-window-point' value is not checked in any of those cases. 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). Tangentially there is a similar case with `quit-window' where an internal marker is set in (window-parameter WIN 'quit-restore) and subject to the above issue whenever the buffer is erased. In that instance, `display-buffer-record-window' does this: (set-window-parameter window 'quit-restore (list 'other ;; A quadruple of WINDOW's buffer, start, point and height. (list (current-buffer) (window-start window) ;; Preserve window-point-insertion-type (Bug#12855). (copy-marker (window-point window) window-point-insertion-type) (if (window-combined-p window) (window-total-height window) (window-total-width window))) (selected-window) buffer))) And `quit-restore-window' does this: ;; Restore WINDOW's previous buffer, start and point position. (set-window-buffer-start-and-point window (nth 0 quad) (nth 1 quad) (nth 2 quad)) This also doesn't test `switch-to-buffer-preserve-window-point' (or anything similar), so the only way of circumventing this behaviour that I can see is to clobber the marker with its own marker position after it's been set. I note that the cases above comprise the *only* standard calls to `set-window-buffer-start-and-point'. Maybe `set-window-buffer-start-and-point' itself should be testing `switch-to-buffer-preserve-window-point' ? -Phil In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2023-04-30 built on phil-lp Repository revision: e03cfec0a455dd8c496d33c422c8edb9ac5a4005 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101004 System Description: Ubuntu 22.04.2 LTS Configured using: 'configure --prefix=/home/phil/emacs/trunk/usr/local --with-x-toolkit=lucid --without-sound '--program-transform-name=s/^ctags$/ctags_emacs/'' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LC_MONETARY: en_NZ.UTF-8 value of $LC_NUMERIC: en_NZ.UTF-8 value of $LC_TIME: en_NZ.UTF-8 value of $LANG: en_GB.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Help Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t isearch-fold-quotes-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-extra cl-print byte-opt gv bytecomp byte-compile help-fns radix-tree help-mode misearch multi-isearch vc-git diff-mode easy-mmode vc-dispatcher jka-compr thingatpt cl-loaddefs cl-lib find-func rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 61926 21737) (symbols 48 6728 0) (strings 32 21712 1476) (string-bytes 1 576559) (vectors 16 12858) (vector-slots 8 183318 15975) (floats 8 32 45) (intervals 56 1270 0) (buffers 976 14)) From unknown Thu Sep 18 18:06:13 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer 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 X-GNU-PR-Keywords: To: 64911@debbugs.gnu.org Cc: Adam Porter Received: via spool by 64911-submit@debbugs.gnu.org id=B64911.169052827729224 (code B ref 64911); Fri, 28 Jul 2023 07:12:03 +0000 Received: (at 64911) by debbugs.gnu.org; 28 Jul 2023 07:11:17 +0000 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 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 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 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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Jul 2023 19:11:07 +1200 From: Phil Sainty In-Reply-To: References: Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 From unknown Thu Sep 18 18:06:13 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jul 2023 07:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Phil Sainty , martin rudalics Cc: adam@alphapapa.net, 64911@debbugs.gnu.org Received: via spool by 64911-submit@debbugs.gnu.org id=B64911.169052884230256 (code B ref 64911); Fri, 28 Jul 2023 07:21:02 +0000 Received: (at 64911) by debbugs.gnu.org; 28 Jul 2023 07:20:42 +0000 Received: from localhost ([127.0.0.1]:43556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPHmC-0007rv-Mv for submit@debbugs.gnu.org; Fri, 28 Jul 2023 03:20:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPHm8-0007rf-W8 for 64911@debbugs.gnu.org; Fri, 28 Jul 2023 03:20:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPHm2-00014H-7h; Fri, 28 Jul 2023 03:20:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WJFFpB0r7M28/cedtpjrjVHsRooxSbpAQetNVYZ07Nk=; b=BscilQzYVpkF wHLnhGNO884GJR/WwyUPPRa+mrm6CZrgJtehqReik3bAH9KLQ+R3BAYLg/m6lpuKt992Aj7rCPT3C eE9n4pLH86ZmqqiRcjMiFlNp20xLTF3ja8jlJyRXV+qZeqTkpW0JMm2RmtnQfaesFmo+8Mwqus8kQ 7CF/eNw5qo7jQRgA0JAFx4igRofCd7mKnDSnacn51pjwWC2uJJUpOf8nMB4nV6bAJtK+zhRu7lfkx ScsGDA8cVWdHUQNgdL5tHiHyso9XNV3WydkEGp8N3NktI3r85MqIRPtzL4WI7MFR6g3/GshqEXd/K zeBRjQH+kQMcaj4nu/A9nw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPHlr-0002iv-Oy; Fri, 28 Jul 2023 03:20:30 -0400 Date: Fri, 28 Jul 2023 10:21:12 +0300 Message-Id: <83sf98jyc7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Phil Sainty on Fri, 28 Jul 2023 17:24:36 +1200) References: X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Adam Porter > Date: Fri, 28 Jul 2023 17:24:36 +1200 > From: Phil Sainty > > The `switch-to-buffer-preserve-window-point' variable determines > whether the (BUFFER WINDOW-START POS) data returned by > `window-prev-buffers' will be used by `switch-to-buffer' to set > the window's start and point positions. > > I think this variable should additionally be respected by both: > > - `switch-to-prev-buffer' > - `switch-to-next-buffer' > > (If not others? These are the cases I'm presently aware of.) Please provide a significant rationale for this change in behavior. This option has proved problematic in quite a few cases since it was introduced: see its uses in the Emacs tree as the evidence of the subtle issues it introduces. So I'm not excited with making it affect even more use cases. We need a sound rationale for such a change (and no, "consistency" is not a sound rationale in my book), and we need to try to audit all the calls to these functions in the tree to understand and anticipate the impacts. > 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. From unknown Thu Sep 18 18:06:13 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jul 2023 11:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64911 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Phil Sainty Cc: adam@alphapapa.net, 64911@debbugs.gnu.org Received: via spool by 64911-submit@debbugs.gnu.org id=B64911.169054222932165 (code B ref 64911); Fri, 28 Jul 2023 11:04:01 +0000 Received: (at 64911) by debbugs.gnu.org; 28 Jul 2023 11:03:49 +0000 Received: from localhost ([127.0.0.1]:43816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPLG8-0008Mj-H6 for submit@debbugs.gnu.org; Fri, 28 Jul 2023 07:03:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPLG6-0008MT-1G for 64911@debbugs.gnu.org; Fri, 28 Jul 2023 07:03:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPLFz-00029u-Tq; Fri, 28 Jul 2023 07:03:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+K0sHJNkSy4oeJgSFMYKr6DjeQt3mF3xyKEUlRbPvZI=; b=iB+fTBB+Sdfs fk4pYYSHckQbH0xtk9/cuGLEDLCUOzssUSuzwUvvhTTMbsQX9Ci154/luwLw0vY1LlbQvqjUNSoPX VF8Lm7U6c0Y8o0OxN3sD+/ZB/8gOcf7ou9KdBL486xBqze9FM0wGnkZxGFW5Ka7pnoT5wMpXq+vl7 OApH/itRT8Bg6OqWjXoCvehRm9B9n7EHqFAEATzmvn6IvPqEuJma34mP/MX/faIzio2leoNNGre76 RYNHS1LwQkX0cq8U7/+bpfVuPRXIhhN0ba/eoYzLuIN4bzuBB/yAyxVh9La7F0jCPP69XEe23yulT UuuIDSF0fjavtoEG/byFEA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPLFc-0004HG-Ga; Fri, 28 Jul 2023 07:03:39 -0400 Date: Fri, 28 Jul 2023 14:04:09 +0300 Message-Id: <83pm4cjo0m.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Phil Sainty on Fri, 28 Jul 2023 19:11:07 +1200) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Adam Porter > Date: Fri, 28 Jul 2023 19:11:07 +1200 > From: Phil Sainty > > 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. Why cannot you use replace-buffer-contents instead of erasing the buffer and rebuilding it? That function attempts to preserve the markers. > 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. In general, when you rebuild the buffer's contents, there's no guarantee the old buffers will be even useful. What markers are we talking about, besides window-point? From unknown Thu Sep 18 18:06:13 2025 X-Loop: help-debbugs@gnu.org Subject: bug#64911: 30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer 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 X-GNU-PR-Keywords: To: Eli Zaretskii , Phil Sainty Cc: adam@alphapapa.net, 64911@debbugs.gnu.org Received: via spool by 64911-submit@debbugs.gnu.org id=B64911.16906181188664 (code B ref 64911); Sat, 29 Jul 2023 08:09:01 +0000 Received: (at 64911) by debbugs.gnu.org; 29 Jul 2023 08:08:38 +0000 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 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 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 Message-ID: <06f426ed-31e4-befe-f4a9-9b1ba70de1bd@gmx.at> Date: Sat, 29 Jul 2023 10:08:17 +0200 MIME-Version: 1.0 Content-Language: en-US References: <83sf98jyc7.fsf@gnu.org> From: martin rudalics In-Reply-To: <83sf98jyc7.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:cV4+nua+7v/B8KZ5w4267G61wCuB2FNfUd9iy86N/qaoHYNU1X6 2oPj1cP/ImjLJ3GgPTQ3aZ+mBeofl2PzkVNR5a6+5q4XebRTzQtUz+pXtAflhb3jelShuj+ fvyCFkBYPlszNkpRZb/90S4DCoiqV9EEHfvm7215981K32p07tn2GdLW3g9MZujAogPXtp3 HDWMd07TyY2P1Lu5O+Vow== X-Spam-Flag: NO 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/q kjby7msAph8CozdbFH8JpidVZK8x77zIUqoM5RfHBXC/mOXjYLHmMgjVccMh4W+RDsz+Qki0M CkJmBUYZcEpPDlBgBg4GXQTpK8mppPaVvtam+NvI9fQOocjkOjH3cVNATFxAcA6XgkzfZAdIo Q0X3/RY7wcX4HbCyoqMJmkR+/Zo= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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