GNU logs - #71616, boring messages


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#71616: switch-to-buffer behaves inconsistently when switch-to-buffer-obey-display-actions is t and nil .
Resent-From: Siyuan Chen <chansey97@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jun 2024 18:18:01 +0000
Resent-Message-ID: <handler.71616.B.171864825030727 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 71616
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 71616 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.171864825030727
          (code B ref -1); Mon, 17 Jun 2024 18:18:01 +0000
Received: (at submit) by debbugs.gnu.org; 17 Jun 2024 18:17:30 +0000
Received: from localhost ([127.0.0.1]:35310 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sJGv3-0007zW-Va
	for submit <at> debbugs.gnu.org; Mon, 17 Jun 2024 14:17:30 -0400
Received: from lists.gnu.org ([209.51.188.17]:60686)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <chansey97@HIDDEN>) id 1sJGv0-0007zM-O5
 for submit <at> debbugs.gnu.org; Mon, 17 Jun 2024 14:17:29 -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 <chansey97@HIDDEN>)
 id 1sJGso-0008SH-O4
 for bug-gnu-emacs@HIDDEN; Mon, 17 Jun 2024 14:15:12 -0400
Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <chansey97@HIDDEN>)
 id 1sJGsi-00069R-V3
 for bug-gnu-emacs@HIDDEN; Mon, 17 Jun 2024 14:15:10 -0400
Received: by mail-yb1-xb2b.google.com with SMTP id
 3f1490d57ef6-dfe43dca3bfso5134032276.0
 for <bug-gnu-emacs@HIDDEN>; Mon, 17 Jun 2024 11:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1718648102; x=1719252902; darn=gnu.org;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=WyxEB9nvKvJFi1qywKE0lIddlKdf82mY8QgAUbdtOXQ=;
 b=eCRl4Zr+pfNLdT05WsEF4RpO7HHFJlGp/OuviD3n4KEJlXJuXVk83jjMB89l9YObWW
 zTxoHRyLp5F6U6xQE5qvJ6LHFk65g0kCMhxMkfaHzzQ+FQa1b+Rg5gzaYDxfRxBrFCgq
 gbBKyEOJDlWo9vbvshO71msqZO6EKqRi58MA/7jXB8fVJKN2G77PHu/o9UVjbwdGpWEw
 oGsUL11udN4CGxZ5BCchJNxJMXi422ZCFfb9GSv+fjRkXxnwhxxFGgpnspC2FlMw5ebj
 WeR/E59m7VYDXXTbD7GlNXWDly7PI4izfrNHkRBvTN3z65vYPczICZzc64FXf0+F/6I6
 y7cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1718648102; x=1719252902;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=WyxEB9nvKvJFi1qywKE0lIddlKdf82mY8QgAUbdtOXQ=;
 b=QNXt8j0FEzNEXmf/QGO5wzjypJFqVbmiFFmnlniBvgIxJwIDTCr6PVRiVWo0e/kuHS
 RvY0PrqIAdmXM8LW7wlrogISKGyPiCnKgU8xTxVek5Co3OM5opoDnsSejVKGJV9uaJcv
 iMXdLCc4CIErYPrHad4pRsSX2fdaIAyAX6eUkySmXnN5p5YU2snFegbVFyAh1Rirswy/
 B3TL7C/jWx/kuAhD/L1cdEHXZKvQN4Vi6XQTldwTa8KH+QAnxGIT4/fKwYaJtJCuaVi1
 c0y2etx80u+eH6SON0RxkCTtvpYj7n+J6q6aL7xVv6g1hqoF9mkXOQouDN6I+7wdloKc
 WjoA==
X-Gm-Message-State: AOJu0YxTmaBTPvDHRF76IJDUybJ0oKtgYmfrueNgV594PVUZ8VPiPjat
 rPc2wE/H9AD7/wYrym1gEKncYvYT0op8DAyMOFcC4a/9mvTHv0+328DMoblA7n/BhnYUGPzOZKk
 5/pnQHg6B3QTUHE1Qkln4kys0Pl14jcszhqY=
X-Google-Smtp-Source: AGHT+IGZUF92y43yRGAiQUBd/j1lju2UWp6fhELRfh5rdU73BRVtInDX4NSUkgB9THqNaQf2zswNgLB/HJaAYVEVGtk=
X-Received: by 2002:a05:6902:11cc:b0:dff:310b:9b40 with SMTP id
 3f1490d57ef6-dff310b9ea5mr6077639276.45.1718648101473; Mon, 17 Jun 2024
 11:15:01 -0700 (PDT)
MIME-Version: 1.0
From: Siyuan Chen <chansey97@HIDDEN>
Date: Tue, 18 Jun 2024 02:14:52 +0800
Message-ID: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000951871061b19f13e"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b2b;
 envelope-from=chansey97@HIDDEN; helo=mail-yb1-xb2b.google.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, 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: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

--000000000000951871061b19f13e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Recently I found a strange behavior about `switch-to-buffer' when
`switch-to-buffer-obey-display-actions' is t.

At the moment, by default, `switch-to-buffer-obey-display-actions' is set
as nil, so `switch-to-buffer' does not be affected by some display-buffer
options, such as `display-buffer-overriding-action',
`display-buffer-alist', etc.

However, if `switch-to-buffer-obey-display-actions' is t,
 `switch-to-buffer' can adapt these display-buffer options. This feature
was introduced by the commit 3f36651c6470bab951f12f486eb4928235f1ba50 and
the implementation is to call `pop-to-buffer-same-window' inside
`switch-to-buffer'.

More details, see
bug#32790
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D3f36651c6470bab951=
f12f486eb4928235f1ba50
https://mail.gnu.org/archive/html/bug-gnu-emacs/2018-11/msg00962.html

The problem is that the `switch-to-buffer' also obeys
`switch-to-buffer-preserve-window-point' while `pop-to-buffer-same-window'
doesn't. Therefore this new feature has to be compatible with
`switch-to-buffer-preserve-window-point' too. This has been implemented in
that commit but not quite right IMHO.

Let's examine the different behaviors when
`switch-to-buffer-obey-display-actions' is nil and t in `switch-to-buffer':

- When `switch-to-buffer-obey-display-actions' is nil,
`switch-to-buffer-preserve-window-point' is t (or nil, no matter actually)
and `(eq buffer (window-buffer))`, the `switch-to-buffer' will do nothing.

- When `switch-to-buffer-obey-display-actions' is t and
`switch-to-buffer-preserve-window-point' is t, `switch-to-buffer' will set
window-point if the target window is the same as the current window (yep,
that is the switch semantics). However, it does not consider what happens
when the target buffer is the same as the current buffer, just like `(eq
buffer (window-buffer))` in the 1st situation!

BTW the `switch-to-buffer-preserve-window-point' docs is a bit confusion:

> This variable is ignored if the buffer is already displayed in
> the selected window or never appeared in it before, or if
> =E2=80=98switch-to-buffer=E2=80=99 calls =E2=80=98pop-to-buffer=E2=80=99 =
to display the buffer,
> or non-nil =E2=80=98switch-to-buffer-obey-display-actions=E2=80=99 displa=
ys it
> in another window.

It doesn't mention what happens if non-nil
=E2=80=98switch-to-buffer-obey-display-actions=E2=80=99 displays it in the =
same window with
the buffer that is already displayed. I also don't know whether the
sentence i.e. "if the buffer is already displayed in the selected window"
includes =E2=80=98switch-to-buffer-obey-display-actions=E2=80=99 is t.

The following are the minimal steps to reproduce.

## Test with default settings:

1. Emacs -Q

2. Open a .el file, e.g. window.el, and keep the cursor location at 1

3. Click buffers menu -> *scratch* to switch buffer

4. Click buffers menu -> window.el to switch buffer back

5. Move the current location to L24

6. M-x switch-to-buffer window.el

The result is that the buffer and window state keeps original, everything
is fine.

## Test with switch-to-buffer-obey-display-actions =3D t

1. Emacs -Q

2. M-x eval-expression (setq switch-to-buffer-obey-display-actions t)

2. Open a .el file, e.g. window.el, and keep the cursor location at 1

3. Click buffers menu -> *scratch* to switch buffer

4. Click buffers menu -> window.el to switch buffer back

5. Move the current location to L24

6. M-x switch-to-buffer window.el

The result is that the current cursor location jumps to location at 1!

This inconsistent behavior convinced me that this is a bug.

Emacs 29.3 on Window.

Thanks.

Best regards,

Siyuan Chen

--000000000000951871061b19f13e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>Recently I found a strange behavior about `swit=
ch-to-buffer&#39; when `switch-to-buffer-obey-display-actions&#39; is t.<br=
><br>At the moment, by default, `switch-to-buffer-obey-display-actions&#39;=
 is set as nil, so `switch-to-buffer&#39; does not be affected by some disp=
lay-buffer options, such as `display-buffer-overriding-action&#39;, `displa=
y-buffer-alist&#39;, etc.<br><br>However, if `switch-to-buffer-obey-display=
-actions&#39; is t, =C2=A0`switch-to-buffer&#39; can adapt these display-bu=
ffer options. This feature was introduced by the commit 3f36651c6470bab951f=
12f486eb4928235f1ba50 and the implementation is to call `pop-to-buffer-same=
-window&#39; inside `switch-to-buffer&#39;.<br><br>More details, see <br>bu=
g#32790<br><a href=3D"https://git.savannah.gnu.org/cgit/emacs.git/commit/?i=
d=3D3f36651c6470bab951f12f486eb4928235f1ba50">https://git.savannah.gnu.org/=
cgit/emacs.git/commit/?id=3D3f36651c6470bab951f12f486eb4928235f1ba50</a><br=
><a href=3D"https://mail.gnu.org/archive/html/bug-gnu-emacs/2018-11/msg0096=
2.html">https://mail.gnu.org/archive/html/bug-gnu-emacs/2018-11/msg00962.ht=
ml</a><br><br>The problem is that the `switch-to-buffer&#39; also obeys `sw=
itch-to-buffer-preserve-window-point&#39; while `pop-to-buffer-same-window&=
#39; doesn&#39;t. Therefore this new feature has to be compatible with `swi=
tch-to-buffer-preserve-window-point&#39; too. This has been implemented in =
that commit but not quite right IMHO.<br><br>Let&#39;s examine the differen=
t behaviors when `switch-to-buffer-obey-display-actions&#39; is nil and t i=
n `switch-to-buffer&#39;:<br><br>- When `switch-to-buffer-obey-display-acti=
ons&#39; is nil, `switch-to-buffer-preserve-window-point&#39; is t (or nil,=
 no matter actually) and `(eq buffer (window-buffer))`, the `switch-to-buff=
er&#39; will do nothing.<br><br>- When `switch-to-buffer-obey-display-actio=
ns&#39; is t and `switch-to-buffer-preserve-window-point&#39; is t, `switch=
-to-buffer&#39; will set window-point if the target window is the same as t=
he current window (yep, that is the switch semantics). However, it does not=
 consider what happens when the target buffer is the same as the current bu=
ffer, just like `(eq buffer (window-buffer))` in the 1st situation!<br><br>=
BTW the `switch-to-buffer-preserve-window-point&#39; docs is a bit confusio=
n:<br><br>&gt; This variable is ignored if the buffer is already displayed =
in<br>&gt; the selected window or never appeared in it before, or if<br>&gt=
; =E2=80=98switch-to-buffer=E2=80=99 calls =E2=80=98pop-to-buffer=E2=80=99 =
to display the buffer,<br>&gt; or non-nil =E2=80=98switch-to-buffer-obey-di=
splay-actions=E2=80=99 displays it<br>&gt; in another window.<br><br>It doe=
sn&#39;t mention what happens if non-nil =E2=80=98switch-to-buffer-obey-dis=
play-actions=E2=80=99 displays it in the same window with the buffer that i=
s already displayed. I also don&#39;t know whether the sentence i.e. &quot;=
if the buffer is already displayed in


the selected window&quot; includes =E2=80=98switch-to-buffer-obey-display-a=
ctions=E2=80=99

is t.<br><br>The following are the minimal steps to reproduce.<br><br>## Te=
st with default settings:<br><br>1. Emacs -Q<br><br>2. Open a .el file, e.g=
. window.el, and keep the cursor location at 1<br><br>3. Click buffers menu=
 -&gt; *scratch* to switch buffer<br><br>4. Click buffers menu -&gt; window=
.el to switch buffer back<br><br>5. Move the current location to L24<br><br=
>6. M-x switch-to-buffer window.el<br><br>The result is that the buffer and=
 window state keeps original, everything is fine.<br><br>## Test with switc=
h-to-buffer-obey-display-actions =3D t<br><br>1. Emacs -Q<br><br>2. M-x eva=
l-expression (setq switch-to-buffer-obey-display-actions t)<br><br>2. Open =
a .el file, e.g. window.el, and keep the cursor location at 1<br><br>3. Cli=
ck buffers menu -&gt; *scratch* to switch buffer<br><br>4. Click buffers me=
nu -&gt; window.el to switch buffer back<br><br>5. Move the current locatio=
n to L24<br><br>6. M-x switch-to-buffer window.el <br><br>The result is tha=
t the current cursor location jumps to location at 1!<br><br>This inconsist=
ent behavior convinced me that this is a bug.<br><div><br></div><div>Emacs =
29.3 on Window.<br></div><div><br></div><div>Thanks.</div><div><br></div><d=
iv>Best regards,</div><div><br></div><div>Siyuan Chen<br></div></div>

--000000000000951871061b19f13e--




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Siyuan Chen <chansey97@HIDDEN>
Subject: bug#71616: Acknowledgement (switch-to-buffer behaves
 inconsistently when switch-to-buffer-obey-display-actions is t and nil .)
Message-ID: <handler.71616.B.171864825030727.ack <at> debbugs.gnu.org>
References: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
X-Gnu-PR-Message: ack 71616
X-Gnu-PR-Package: emacs
Reply-To: 71616 <at> debbugs.gnu.org
Date: Mon, 17 Jun 2024 18:18:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 71616 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
71616: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D71616
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#71616: switch-to-buffer behaves inconsistently when switch-to-buffer-obey-display-actions is t and nil .
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jun 2024 18:37:01 +0000
Resent-Message-ID: <handler.71616.B71616.171864937432645 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71616
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 71616 <at> debbugs.gnu.org, Siyuan Chen <chansey97@HIDDEN>
Received: via spool by 71616-submit <at> debbugs.gnu.org id=B71616.171864937432645
          (code B ref 71616); Mon, 17 Jun 2024 18:37:01 +0000
Received: (at 71616) by debbugs.gnu.org; 17 Jun 2024 18:36:14 +0000
Received: from localhost ([127.0.0.1]:35338 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sJHDB-0008US-Ps
	for submit <at> debbugs.gnu.org; Mon, 17 Jun 2024 14:36:14 -0400
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:35919)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1sJHD6-0008Tp-LQ
 for 71616 <at> debbugs.gnu.org; Mon, 17 Jun 2024 14:36:12 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 6803140004;
 Mon, 17 Jun 2024 18:35:36 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
 (Siyuan Chen's message of "Tue, 18 Jun 2024 02:14:52 +0800")
Organization: LINKOV.NET
References: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
Date: Mon, 17 Jun 2024 21:34:18 +0300
Message-ID: <86bk3zxvth.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> Recently I found a strange behavior about `switch-to-buffer' when
> `switch-to-buffer-obey-display-actions' is t.
>
> At the moment, by default, `switch-to-buffer-obey-display-actions' is set
> as nil, so `switch-to-buffer' does not be affected by some display-buffer
> options, such as `display-buffer-overriding-action',
> `display-buffer-alist', etc.
>
> However, if `switch-to-buffer-obey-display-actions' is t, 
> `switch-to-buffer' can adapt these display-buffer options. This feature was
> introduced by the commit 3f36651c6470bab951f12f486eb4928235f1ba50 and the
> implementation is to call `pop-to-buffer-same-window' inside
> `switch-to-buffer'.
>
> More details, see 
> bug#32790
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3f36651c6470bab951f12f486eb4928235f1ba50
>
> https://mail.gnu.org/archive/html/bug-gnu-emacs/2018-11/msg00962.html
>
> The problem is that the `switch-to-buffer' also obeys
> `switch-to-buffer-preserve-window-point' while `pop-to-buffer-same-window'
> doesn't. Therefore this new feature has to be compatible with
> `switch-to-buffer-preserve-window-point' too. This has been implemented in
> that commit but not quite right IMHO.
>
> Let's examine the different behaviors when
> `switch-to-buffer-obey-display-actions' is nil and t in `switch-to-buffer':
>
> - When `switch-to-buffer-obey-display-actions' is nil,
> `switch-to-buffer-preserve-window-point' is t (or nil, no matter actually)
> and `(eq buffer (window-buffer))`, the `switch-to-buffer' will do nothing.
>
> - When `switch-to-buffer-obey-display-actions' is t and
> `switch-to-buffer-preserve-window-point' is t, `switch-to-buffer' will set
> window-point if the target window is the same as the current window (yep,
> that is the switch semantics). However, it does not consider what happens
> when the target buffer is the same as the current buffer, just like `(eq
> buffer (window-buffer))` in the 1st situation!
>
> BTW the `switch-to-buffer-preserve-window-point' docs is a bit confusion:
>
>> This variable is ignored if the buffer is already displayed in
>> the selected window or never appeared in it before, or if
>> ‘switch-to-buffer’ calls ‘pop-to-buffer’ to display the buffer,
>> or non-nil ‘switch-to-buffer-obey-display-actions’ displays it
>> in another window.
>
> It doesn't mention what happens if non-nil
> ‘switch-to-buffer-obey-display-actions’ displays it in the same window with
> the buffer that is already displayed. I also don't know whether the
> sentence i.e. "if the buffer is already displayed in the selected window"
> includes ‘switch-to-buffer-obey-display-actions’ is t.
>
> The following are the minimal steps to reproduce.
>
> ## Test with default settings:
> 1. Emacs -Q
> 2. Open a .el file, e.g. window.el, and keep the cursor location at 1
> 3. Click buffers menu -> *scratch* to switch buffer
> 4. Click buffers menu -> window.el to switch buffer back
> 5. Move the current location to L24
> 6. M-x switch-to-buffer window.el
>
> The result is that the buffer and window state keeps original, everything
> is fine.
>
> ## Test with switch-to-buffer-obey-display-actions = t
> 1. Emacs -Q
> 2. M-x eval-expression (setq switch-to-buffer-obey-display-actions t)
> 2. Open a .el file, e.g. window.el, and keep the cursor location at 1
> 3. Click buffers menu -> *scratch* to switch buffer
> 4. Click buffers menu -> window.el to switch buffer back
> 5. Move the current location to L24
> 6. M-x switch-to-buffer window.el 
> The result is that the current cursor location jumps to location at 1!
> This inconsistent behavior convinced me that this is a bug.

I confirm this in Emacs 30.  Maybe Martin could suggest how to fix this.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#71616: switch-to-buffer behaves inconsistently when switch-to-buffer-obey-display-actions is t and nil .
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 19 Jun 2024 09:38:01 +0000
Resent-Message-ID: <handler.71616.B71616.171878986627794 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71616
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Juri Linkov <juri@HIDDEN>
Cc: 71616 <at> debbugs.gnu.org, Siyuan Chen <chansey97@HIDDEN>
Received: via spool by 71616-submit <at> debbugs.gnu.org id=B71616.171878986627794
          (code B ref 71616); Wed, 19 Jun 2024 09:38:01 +0000
Received: (at 71616) by debbugs.gnu.org; 19 Jun 2024 09:37:46 +0000
Received: from localhost ([127.0.0.1]:38306 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sJrlC-0007EC-8X
	for submit <at> debbugs.gnu.org; Wed, 19 Jun 2024 05:37:46 -0400
Received: from mout.gmx.net ([212.227.17.21]:47387)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1sJrl9-0007Du-L8
 for 71616 <at> debbugs.gnu.org; Wed, 19 Jun 2024 05:37:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
 s=s31663417; t=1718789853; x=1719394653; i=rudalics@HIDDEN;
 bh=3ZffiXluclp8Vww/Uv+kSIkoeIal2k+qUdBErVZIDkE=;
 h=X-UI-Sender-Class:Content-Type:Message-ID:Date:MIME-Version:
 Subject:To:Cc:References:From:In-Reply-To:cc:
 content-transfer-encoding:content-type:date:from:message-id:
 mime-version:reply-to:subject:to;
 b=Yud0U+qEunKvo40bACB9IHsk9vf5TVkf2OYz/k4eiA34qx1OM2wWww3hT8mEKC3W
 kUBFaw59Ili+mSRH51orogVlyxPmKGMTGhUc4RRfab9OdwD23bFsdJre6iE+oHcUj
 gRu4eU0ZYM5gCG90lV6OmCasEc1IiwANAYbWWnZvk6OPwpEudOLF7P6Nb3fclxIRN
 FInthIoAJKYNGWX0Cb/3JyzYVmuDXL1n0W6RJqb0myXZ7rYHT8SsHG/lcn0OxE2OC
 UeDVyD2uCo8ncr/PzLLSdvaOK4p1EsN7/QniIUJI9wL1wmAKWfDrX0R2HMT1ArOmg
 ZKRIFYrQMlDHnwj6jA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.224]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5VHG-1sPprD1C3O-00s263; Wed, 19
 Jun 2024 11:37:33 +0200
Content-Type: multipart/mixed; boundary="------------AQZYWU8ViwrQgeXx8RM2jtb5"
Message-ID: <faed666a-d23f-4d3e-b845-ec8741cbfdbc@HIDDEN>
Date: Wed, 19 Jun 2024 11:37:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
 <86bk3zxvth.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86bk3zxvth.fsf@HIDDEN>
X-Provags-ID: V03:K1:7hNuGWGtVAp34o5tpL9IE29EBssF2HUEOpamK42n9lMj/MMkNni
 b57MVcAXdpwjx6n4o83nlz69gHKPgYzr7/YxUK8OAcOs+Y6vdDih6MtWbsFZ9tLmveR4SrQ
 FzMSsQP37rNEei3qOwey4oMW2LrE39ePb3wAIxW6Xj44xWeR3LiVxL5JsidXoOStnncn5de
 Hgqw0DhLff9+4i374ZASg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:kf+4dWF4s6U=;w4UilMJOMQBVmAHXEXeQemF6gaU
 Py0azP9zZ4+oKCimswODNwXoyg70266jDGpAQtKho5C3WlvrXGPZI0HVml9K3bJWVAg9XEdRw
 xVLBkSDB7H6oKLyio3Pa6lr1pLb6q7ROanbVM5etZLjHa5FQjGZJLPOIGBx6+4apPMxgjUPnH
 aASNfIgjlaLmxiI5cCCjQiGP3vN0ya8A/FV/SSjJ4m4nWIOSPt7MB3XVdoYH7ZmEdHc+dD1rm
 YGnKjmF6pxQdQJfAqhYLvOOabKMvKERXUlh0eWgkOga0BKK1uL+Akksz39vFi71aqIluZeZZ3
 AAzBOLE7N33eiQF00/jFNjYgOXJdxxbXhb8x9Gdgu0YweUz4M9vm3fOENTFwfOM8vtbvOwIl2
 xGs+FXduOP6zK+Q9f+FucNZZQb/HAi9bs5L+kqtxnr8lhpx+c0pRqEkNaNXKIxrl3YDHjdrRW
 +Wup4jEgPMRCbE7Hn4xZbBX1POrueLg/HjYz9UOUSrnESUgQ4u00Z6hJs7ECI5W2qI240T4pF
 qelg48pSa0jYJFt08TBAkrI8zIwdf7A0nDG3YS1Lmd1svJGve2hnwdec76s1oLUT2wGF++5av
 IdBh8lwrWE39J2RE6V5HIVLB4AS7pvJdB/g4cF7XtJLVEzQqZmTi9L88o82UviLvoWpwcy6/v
 jjngf+iOi+EkejZ1xHUIkt0NrlpRd7ZIwF4ItgqvhyUk1UL7/Ncxs6qLQSE/mUVjIVuSZVRkx
 7KkPvjej8tOfayTOBZ5LuLs0d544190S8nYQVdBD+PImzn5Mx+/bKhuoFNhwbSShkOrGVg7uZ
 3lyrrD0Jpzr4hAqeOrxV8A8bDy90c/2JPv0OI7WUUaA2o=
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  >> ## Test with switch-to-buffer-obey-display-actions = t
 >> 1. Emacs -Q >> 2. M-x eval-expression (setq
 switch-to-buffer-obey-display-actions
 t) >> 2. Open a .el file, e.g. window.el, and keep the c [...] 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.17.21 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [212.95.5.224 listed in zen.spamhaus.org]
 0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
 [212.227.17.21 listed in wl.mailspike.net]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  >> ## Test with switch-to-buffer-obey-display-actions = t
    >> 1. Emacs -Q >> 2. M-x eval-expression (setq switch-to-buffer-obey-display-actions
    t) >> 2. Open a .el file, e.g. window.el, and keep the c [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [212.95.5.224 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.17.21 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
                             [212.227.17.21 listed in wl.mailspike.net]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

This is a multi-part message in MIME format.
--------------AQZYWU8ViwrQgeXx8RM2jtb5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

 >> ## Test with switch-to-buffer-obey-display-actions = t
 >> 1. Emacs -Q
 >> 2. M-x eval-expression (setq switch-to-buffer-obey-display-actions t)
 >> 2. Open a .el file, e.g. window.el, and keep the cursor location at 1
 >> 3. Click buffers menu -> *scratch* to switch buffer
 >> 4. Click buffers menu -> window.el to switch buffer back
 >> 5. Move the current location to L24
 >> 6. M-x switch-to-buffer window.el
 >> The result is that the current cursor location jumps to location at 1!
 >> This inconsistent behavior convinced me that this is a bug.
 >
 > I confirm this in Emacs 30.  Maybe Martin could suggest how to fix
 >> this.

A recipe without involving a file is

1. M-: (setq switch-to-buffer-obey-display-actions t)
2. C-x b *Messages*
3. C-x b *scratch*
4. Move point
5. C-x b *scratch*

In step 2 we record the point of *scratch*.  In 5 we go there because
the 'set-window-buffer' called by C-x b decides that the window already
shows buffer and does not record its current position.  I attach a patch
that should fix this and the original scenario.  It does _not_ fix the
case where instead of C-x b plain 'set-window-buffer' is used.  If we
wanted to fix that, we'd have to call 'record-window-buffer' from there
even when the old and the new buffer are the same.  I'm not sure whether
we want to do that.

martin
--------------AQZYWU8ViwrQgeXx8RM2jtb5
Content-Type: text/x-patch; charset=UTF-8;
 name="switch-to-buffer-obey-display-actions.diff"
Content-Disposition: attachment;
 filename="switch-to-buffer-obey-display-actions.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2xpc3Avd2luZG93LmVsIGIvbGlzcC93aW5kb3cuZWwKaW5kZXggNjA0
Yjk4Njg5MjEuLjJmZjQ5MjhjMTFlIDEwMDY0NAotLS0gYS9saXNwL3dpbmRvdy5lbAorKysg
Yi9saXNwL3dpbmRvdy5lbApAQCAtOTE3MSw5ICs5MjQzLDE0IEBAIHN3aXRjaC10by1idWZm
ZXIKICAgICAgICAgKHBvcC10by1idWZmZXIgYnVmZmVyIG5vcmVjb3JkKSkpCiAgICAgICh0
CiAgICAgICAod2hlbiBzd2l0Y2gtdG8tYnVmZmVyLW9iZXktZGlzcGxheS1hY3Rpb25zCi0g
ICAgICAgIChsZXQgKChzZWxlY3RlZC13aW5kb3cgKHNlbGVjdGVkLXdpbmRvdykpKQorICAg
ICAgICAobGV0KiAoKHNlbGVjdGVkLXdpbmRvdyAoc2VsZWN0ZWQtd2luZG93KSkKKwkgICAg
ICAgKG9sZC13aW5kb3ctYnVmZmVyICh3aW5kb3ctYnVmZmVyIHNlbGVjdGVkLXdpbmRvdykp
KQogICAgICAgICAgIChwb3AtdG8tYnVmZmVyLXNhbWUtd2luZG93IGJ1ZmZlciBub3JlY29y
ZCkKLSAgICAgICAgICAod2hlbiAoZXEgKHNlbGVjdGVkLXdpbmRvdykgc2VsZWN0ZWQtd2lu
ZG93KQorCSAgOzsgRG8gbm90IGFzayBmb3Igc2V0dGluZyBzdGFydCBhbmQgcG9pbnQgd2hl
biBzaG93aW5nIHRoZQorCSAgOzsgc2FtZSBidWZmZXIgaW4gdGhlIG9sZCBzZWxlY3RlZCB3
aW5kb3cgKEJ1ZyM3MTYxNikuCisgICAgICAgICAgKHdoZW4gKGFuZCAoZXEgKHNlbGVjdGVk
LXdpbmRvdykgc2VsZWN0ZWQtd2luZG93KQorCQkgICAgIChub3QgKGVxICh3aW5kb3ctYnVm
ZmVyIHNlbGVjdGVkLXdpbmRvdykKKwkJCSAgICAgIG9sZC13aW5kb3ctYnVmZmVyKSkpCiAg
ICAgICAgICAgICAoc2V0cSBzZXQtd2luZG93LXN0YXJ0LWFuZC1wb2ludCB0KSkpKQogCiAg
ICAgICAod2hlbiBzZXQtd2luZG93LXN0YXJ0LWFuZC1wb2ludAo=

--------------AQZYWU8ViwrQgeXx8RM2jtb5--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#71616: switch-to-buffer behaves inconsistently when switch-to-buffer-obey-display-actions is t and nil .
Resent-From: Siyuan Chen <chansey97@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 23 Jun 2024 05:46:01 +0000
Resent-Message-ID: <handler.71616.B71616.171912152331578 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71616
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 71616 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
Received: via spool by 71616-submit <at> debbugs.gnu.org id=B71616.171912152331578
          (code B ref 71616); Sun, 23 Jun 2024 05:46:01 +0000
Received: (at 71616) by debbugs.gnu.org; 23 Jun 2024 05:45:23 +0000
Received: from localhost ([127.0.0.1]:45612 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sLG2V-0008Bh-4v
	for submit <at> debbugs.gnu.org; Sun, 23 Jun 2024 01:45:23 -0400
Received: from mail-yb1-f179.google.com ([209.85.219.179]:56485)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <chansey97@HIDDEN>) id 1sLG2U-0007tx-4i
 for 71616 <at> debbugs.gnu.org; Sun, 23 Jun 2024 01:45:22 -0400
Received: by mail-yb1-f179.google.com with SMTP id
 3f1490d57ef6-e02748b2402so3471171276.0
 for <71616 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 22:45:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719121456; x=1719726256; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=vsxituNDic4YvrV0IIx/pqCpWayvaa+70oaq0LjKzws=;
 b=hVFvg90DbJKDtdk2ujdOBEeR0PtG54yrnZpUY2A5J3yHcavMLPaN8+1itB5Vc2AxXp
 Zv/xInmbJSCq+xHrwLTKee7Xm527QgXRPwaqHQSYtHlX2DAkKYZDhWNJAUaAjyy7qX/f
 lUU78vELLeckNZQpdkyYhFgApHGRv6Oh75p1d4WRlLdV75x5KYd09mV+ekpdBPYt3+bt
 RdObw/w4gGC30SDltValPlh7ILbZ8uIWNd9aPCx1Rn4s8LwYRZ8TS5mZjTUzBu/BiMZ7
 YtgUP/7aLbZxttuhXN/Wpk9MSZ0EaMD+tKJgJjZ/ZvMX7EDwd93lyMzhg9jCqfRG370t
 eeiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719121456; x=1719726256;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=vsxituNDic4YvrV0IIx/pqCpWayvaa+70oaq0LjKzws=;
 b=I2lK3en4kx/9KJc5bEmaZvqjB8SPUT4qet7pY0a/2ByhOLybz5EJY3hNzqrIYu7SJ5
 KXcwkXxXbXc2ohzaJK0ALZsYDaFKpr6rXTJ89MvMya3UuVmZqP4K+9IRkTmuokDdjenG
 sT1K1ZiytRuW7eEuZaU8fU9j3oLG5tXBsNEiVkP/r3YYLxfH+EZc23R/1DLAUYahxcCw
 gmT/FWSIU6zWx3wSbbDHk77CChsw73mLiMwzUxkb1ykIZJdbLpiCcdbcEyFBSXvzd7Ov
 zO4t7TPeH2yqK+pcdLzvEqznBZUFdHpQYC3JUolpdQiNG+Ql5ZeRbHYlCkPSMKb1oZy4
 2qNw==
X-Forwarded-Encrypted: i=1;
 AJvYcCUKKG69OGSh83VCQxp6gnOG+ULe8L+Kl6wZwAwotxmKaNczIAXNh16+y6p4frRimb5u6KJQcEXZG8aKIb/iKKGJ92M8AxA=
X-Gm-Message-State: AOJu0YxnRU2QQFJxno/mcNqNI4BxsuiPs+WI0vjz32u2qiNVA+bmyskU
 XHz6MWzaVSrqs1TWR1ni9KQKg9H4K9Gy8fWjqDxUicaHY32uUsSJ8Wme4MTyk4NURWafoBdpRL8
 J8AfoYJEWq091M3pjQ2D7y4+qqQk=
X-Google-Smtp-Source: AGHT+IEhPgLhanC3j8dJj61PzshlNueLJ0nDTtU8sv+oyUHtoTFAC+9u/y4By9SckS0u3lJLzHzZ4ve7JCJ+DR9EU5Y=
X-Received: by 2002:a05:6902:2486:b0:e02:bf87:7cc7 with SMTP id
 3f1490d57ef6-e0304025c08mr1308041276.64.1719121456348; Sat, 22 Jun 2024
 22:44:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAHWTsYky_hvJAyxPsv2iAEvCUJcxdE-PJHk0JsbiP41A1B9CXg@HIDDEN>
 <86bk3zxvth.fsf@HIDDEN> <faed666a-d23f-4d3e-b845-ec8741cbfdbc@HIDDEN>
In-Reply-To: <faed666a-d23f-4d3e-b845-ec8741cbfdbc@HIDDEN>
From: Siyuan Chen <chansey97@HIDDEN>
Date: Sun, 23 Jun 2024 13:44:07 +0800
Message-ID: <CAHWTsYnPRYhP9y=htdG1bvvADZ7yWVAhe6dSo83zkFrf6EtSEw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000bb46ff061b882779"
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

--000000000000bb46ff061b882779
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This patch fixed my original use case, which did not touch
'set-window-buffer'.

Thanks.

Best regards,
Siyuan Chen

On Wed, Jun 19, 2024 at 5:37=E2=80=AFPM martin rudalics <rudalics@HIDDEN> w=
rote:

>  >> ## Test with switch-to-buffer-obey-display-actions =3D t
>  >> 1. Emacs -Q
>  >> 2. M-x eval-expression (setq switch-to-buffer-obey-display-actions t)
>  >> 2. Open a .el file, e.g. window.el, and keep the cursor location at 1
>  >> 3. Click buffers menu -> *scratch* to switch buffer
>  >> 4. Click buffers menu -> window.el to switch buffer back
>  >> 5. Move the current location to L24
>  >> 6. M-x switch-to-buffer window.el
>  >> The result is that the current cursor location jumps to location at 1=
!
>  >> This inconsistent behavior convinced me that this is a bug.
>  >
>  > I confirm this in Emacs 30.  Maybe Martin could suggest how to fix
>  >> this.
>
> A recipe without involving a file is
>
> 1. M-: (setq switch-to-buffer-obey-display-actions t)
> 2. C-x b *Messages*
> 3. C-x b *scratch*
> 4. Move point
> 5. C-x b *scratch*
>
> In step 2 we record the point of *scratch*.  In 5 we go there because
> the 'set-window-buffer' called by C-x b decides that the window already
> shows buffer and does not record its current position.  I attach a patch
> that should fix this and the original scenario.  It does _not_ fix the
> case where instead of C-x b plain 'set-window-buffer' is used.  If we
> wanted to fix that, we'd have to call 'record-window-buffer' from there
> even when the old and the new buffer are the same.  I'm not sure whether
> we want to do that.
>
> martin

--000000000000bb46ff061b882779
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This patch fixed my original use case, which did not =
touch &#39;set-window-buffer&#39;.</div><div><br></div><div>Thanks.</div><d=
iv><br></div><div>Best regards,</div><div>Siyuan Chen<br></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun =
19, 2024 at 5:37=E2=80=AFPM martin rudalics &lt;<a href=3D"mailto:rudalics@=
gmx.at">rudalics@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">=C2=A0&gt;&gt; ## Test with switch-to-buffer-obey-di=
splay-actions =3D t<br>
=C2=A0&gt;&gt; 1. Emacs -Q<br>
=C2=A0&gt;&gt; 2. M-x eval-expression (setq switch-to-buffer-obey-display-a=
ctions t)<br>
=C2=A0&gt;&gt; 2. Open a .el file, e.g. window.el, and keep the cursor loca=
tion at 1<br>
=C2=A0&gt;&gt; 3. Click buffers menu -&gt; *scratch* to switch buffer<br>
=C2=A0&gt;&gt; 4. Click buffers menu -&gt; window.el to switch buffer back<=
br>
=C2=A0&gt;&gt; 5. Move the current location to L24<br>
=C2=A0&gt;&gt; 6. M-x switch-to-buffer window.el<br>
=C2=A0&gt;&gt; The result is that the current cursor location jumps to loca=
tion at 1!<br>
=C2=A0&gt;&gt; This inconsistent behavior convinced me that this is a bug.<=
br>
=C2=A0&gt;<br>
=C2=A0&gt; I confirm this in Emacs 30.=C2=A0 Maybe Martin could suggest how=
 to fix<br>
=C2=A0&gt;&gt; this.<br>
<br>
A recipe without involving a file is<br>
<br>
1. M-: (setq switch-to-buffer-obey-display-actions t)<br>
2. C-x b *Messages*<br>
3. C-x b *scratch*<br>
4. Move point<br>
5. C-x b *scratch*<br>
<br>
In step 2 we record the point of *scratch*.=C2=A0 In 5 we go there because<=
br>
the &#39;set-window-buffer&#39; called by C-x b decides that the window alr=
eady<br>
shows buffer and does not record its current position.=C2=A0 I attach a pat=
ch<br>
that should fix this and the original scenario.=C2=A0 It does _not_ fix the=
<br>
case where instead of C-x b plain &#39;set-window-buffer&#39; is used.=C2=
=A0 If we<br>
wanted to fix that, we&#39;d have to call &#39;record-window-buffer&#39; fr=
om there<br>
even when the old and the new buffer are the same.=C2=A0 I&#39;m not sure w=
hether<br>
we want to do that.<br>
<br>
martin</blockquote></div>

--000000000000bb46ff061b882779--





Last modified: Sun, 23 Jun 2024 05:45:02 UTC

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