GNU bug report logs - #64911
30.0.50; switch-to-buffer-preserve-window-point not respected by switch-to-(next|prev)-buffer

Previous Next

Full log

Message #11 received at 64911 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>, martin rudalics <rudalics <at> gmx.at>
Cc: adam <at> alphapapa.net, 64911 <at> debbugs.gnu.org
Subject: Re: bug#64911: 30.0.50;
 switch-to-buffer-preserve-window-point not respected by
 switch-to-(next|prev)-buffer
Date: Fri, 28 Jul 2023 10:21:12 +0300

> Cc: Adam Porter <adam <at> alphapapa.net>
> Date: Fri, 28 Jul 2023 17:24:36 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.