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' when `switch-to-buffer-obey-display-actions' is t.<br= ><br>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 disp= lay-buffer options, such as `display-buffer-overriding-action', `displa= y-buffer-alist', etc.<br><br>However, if `switch-to-buffer-obey-display= -actions' is t, =C2=A0`switch-to-buffer' 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' inside `switch-to-buffer'.<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' also obeys `sw= itch-to-buffer-preserve-window-point' while `pop-to-buffer-same-window&= #39; doesn't. Therefore this new feature has to be compatible with `swi= tch-to-buffer-preserve-window-point' too. This has been implemented in = that commit but not quite right IMHO.<br><br>Let's examine the differen= t behaviors when `switch-to-buffer-obey-display-actions' is nil and t i= n `switch-to-buffer':<br><br>- When `switch-to-buffer-obey-display-acti= ons' is nil, `switch-to-buffer-preserve-window-point' is t (or nil,= no matter actually) and `(eq buffer (window-buffer))`, the `switch-to-buff= er' will do nothing.<br><br>- When `switch-to-buffer-obey-display-actio= ns' 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 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' docs is a bit confusio= n:<br><br>> This variable is ignored if the buffer is already displayed = in<br>> the selected window or never appeared in it before, or if<br>>= ; =E2=80=98switch-to-buffer=E2=80=99 calls =E2=80=98pop-to-buffer=E2=80=99 = to display the buffer,<br>> or non-nil =E2=80=98switch-to-buffer-obey-di= splay-actions=E2=80=99 displays it<br>> in another window.<br><br>It doe= sn'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'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-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= -> *scratch* to switch buffer<br><br>4. Click buffers menu -> 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 -> *scratch* to switch buffer<br><br>4. Click buffers me= nu -> 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--
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
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.
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--
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 'set-window-buffer'.</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 <<a href=3D"mailto:rudalics@= gmx.at">rudalics@HIDDEN</a>> 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>> ## Test with switch-to-buffer-obey-di= splay-actions =3D t<br> =C2=A0>> 1. Emacs -Q<br> =C2=A0>> 2. M-x eval-expression (setq switch-to-buffer-obey-display-a= ctions t)<br> =C2=A0>> 2. Open a .el file, e.g. window.el, and keep the cursor loca= tion at 1<br> =C2=A0>> 3. Click buffers menu -> *scratch* to switch buffer<br> =C2=A0>> 4. Click buffers menu -> window.el to switch buffer back<= br> =C2=A0>> 5. Move the current location to L24<br> =C2=A0>> 6. M-x switch-to-buffer window.el<br> =C2=A0>> The result is that the current cursor location jumps to loca= tion at 1!<br> =C2=A0>> This inconsistent behavior convinced me that this is a bug.<= br> =C2=A0><br> =C2=A0> I confirm this in Emacs 30.=C2=A0 Maybe Martin could suggest how= to fix<br> =C2=A0>> 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 'set-window-buffer' 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 'set-window-buffer' is used.=C2= =A0 If we<br> wanted to fix that, we'd have to call 'record-window-buffer' fr= om there<br> even when the old and the new buffer are the same.=C2=A0 I'm not sure w= hether<br> we want to do that.<br> <br> martin</blockquote></div> --000000000000bb46ff061b882779--
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.