From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: jan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Mar 2016 23:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 23131@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14591218622610 (code B ref -1); Sun, 27 Mar 2016 23:38:01 +0000 Received: (at submit) by debbugs.gnu.org; 27 Mar 2016 23:37:42 +0000 Received: from localhost ([127.0.0.1]:40516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akKFa-0000g2-7B for submit@debbugs.gnu.org; Sun, 27 Mar 2016 19:37:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akKFY-0000fp-Ta for submit@debbugs.gnu.org; Sun, 27 Mar 2016 19:37:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akKFS-0001ww-Gj for submit@debbugs.gnu.org; Sun, 27 Mar 2016 19:37:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:39446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akKFS-0001wr-CW for submit@debbugs.gnu.org; Sun, 27 Mar 2016 19:37:34 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akKFR-0001nv-1k for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 19:37:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akKFP-0001ve-Ug for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 19:37:32 -0400 Received: from mail-qk0-x235.google.com ([2607:f8b0:400d:c09::235]:33338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akKFP-0001vW-Oq for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2016 19:37:31 -0400 Received: by mail-qk0-x235.google.com with SMTP id s5so90891838qkd.0 for ; Sun, 27 Mar 2016 16:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=gzwF54hwPYCvYlyBFUeWFCpRpgqZtHi8KOrEHfPH2Ds=; b=E+rtmzxzmt1t5z/xZEg1+yqCztTLf/u+9XEof8UklVQW3VyFP5QlZgwyhjJoeotjbR QMufuboDnCQuNvOT1o17osOOHAqOsHMCwEt8tjJY9mO1+yValiKQZqpD/BHmVbigFEOI xDrw+92pdWLv7moTFZFfd7wqZQyuXKgq8ECukAyMJaD+EwDAOm180ESjyuYHMPVDEAIu w2wHIu1JzD8K2jDpcf6mH+lHWyZE6UeaOFFVhggD2nRd0d7WdELMutZ/5J1dCg2Vc/RW VHyk9p7/wfXJ1jueZbWBQXrxGwxNOPsq3Nk2TF6vR0PmBfePVwJFUXgj149i2cgJO0lD 38Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=gzwF54hwPYCvYlyBFUeWFCpRpgqZtHi8KOrEHfPH2Ds=; b=KIDtuaMq7a/l11vm37WmGBaFqy60rdgTIg3+i0f6A6gpuM/kcJaXpc+c+czBd/+1PY mSHJtkZE0eRtJgIJhAhqqEOg1UzRBP/D//HJq476zJf9zvrdQWqLH3gkdBVZGAbtxSuF z2hbt8Y9qlU2S5qXd9T0EeOn0Ekm2fHe5XtzNNsy50luPu1gaQ/JgJnWqZNA0o/GrACl cYEXnpastqkad2to6bXYFxO78nkOo4nJQOtkIcyfvwn7iiiLjGWZuRXg3jeZ7zYMeXPU AR55+7XznNcmKQC2fLNdAJPLlh9BbRgQiGHRZUgMj3v3P8I2a3O8t3E5mw43+7NCqByK HKqA== X-Gm-Message-State: AD7BkJJsokNLvDl7sOTZchyrfFmBQWSIywgJHgYkHFbeXr2mn/SP4yNS5YvizttXoSlNRJlldXttivHNIHk07A== MIME-Version: 1.0 X-Received: by 10.37.230.73 with SMTP id d70mr3008999ybh.138.1459121851023; Sun, 27 Mar 2016 16:37:31 -0700 (PDT) Received: by 10.37.65.195 with HTTP; Sun, 27 Mar 2016 16:37:30 -0700 (PDT) Date: Mon, 28 Mar 2016 00:37:30 +0100 Message-ID: From: jan Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.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: -4.0 (----) Running emacs 24.5.1 on windows. Hi all, switch-to-buffer-other-frame works but should prompt for the name of the buffer to switch to. Per the help on that function "If called interactively, prompt for the buffer name using the minibuffer". Well it does but then refuses to recognise my buffer by name. --------- e.g Start emacs, then drag a file (say sample.txt) onto it. File opens fine. Type C-x 5 b - minibuffer shows "Switch to buffer in other frame (default *GNU Emacs*): " I type "sam" [tab key for completion] - minibuffer says "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]" odd. If I remove the "sam" I just typed then type '?' to show the buffer list, it opens a 2nd buffer at the bottom and shows Possible completions are: *GNU Emacs* *Messages* *scratch* which does not show sample.txt, which is definitly there as I can see it open in the buffer at the top. As a workaround, I enter a nonexistent buffer name, the 2nd frame opens, blank, I then do C-x b sam <- I type this in [tab for completion] sample.txt <- emacs autocompletes this RET <- to accept and sample.txt is now shown in the other frame as I want. But this is a workaround. ---------------- Having raised this with Eli, he says this is expected behaviour: "Yes, it's a feature: Emacs doesn't offer you a buffer that is already displayed in an existing window. This was introduced in Emacs 24." Well, a) this is not documented (see below) and b) I can't see any rationale for this behaviour. Hiding this option does not assist the user in any way I can see. Also, the behaviour is apparently broken if the current buffer/window is split: a. open sample.txt b. C-x 2 -- split window in 2, top and bottom c. C-x 5 b -- try to get 2nd frame d. sample.txt -- type in full filename in minibuffer e. 2nd frame does *not* appear, cursor jumps to top of split window, even if was originally in bottom. can reproduce? jan I said this behaviour isn't documented that I can see. Here's the full docs for this function. It says nothing about hiding the current buffer name: ------- switch-to-buffer-other-frame is an interactive compiled Lisp function in `window.el'. It is bound to C-x 5 b. (switch-to-buffer-other-frame BUFFER-OR-NAME &optional NORECORD) Switch to buffer BUFFER-OR-NAME in another frame. BUFFER-OR-NAME may be a buffer, a string (a buffer name), or nil. Return the buffer switched to. If called interactively, prompt for the buffer name using the minibuffer. The variable `confirm-nonexistent-file-or-buffer' determines whether to request confirmation before creating a new buffer. If BUFFER-OR-NAME is a string and does not identify an existing buffer, create a new buffer with that name. If BUFFER-OR-NAME is nil, switch to the buffer returned by `other-buffer'. Optional second arg NORECORD non-nil means do not put this buffer at the front of the list of recently selected ones. This uses the function `display-buffer' as a subroutine; see its documentation for additional customization information. ------- From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Mar 2016 11:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: jan , 23131@debbugs.gnu.org Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.14591641792923 (code B ref 23131); Mon, 28 Mar 2016 11:23:02 +0000 Received: (at 23131) by debbugs.gnu.org; 28 Mar 2016 11:22:59 +0000 Received: from localhost ([127.0.0.1]:40837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVG6-0000l5-Vz for submit@debbugs.gnu.org; Mon, 28 Mar 2016 07:22:59 -0400 Received: from mout.gmx.net ([212.227.17.21]:49349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akVG5-0000ko-2d for 23131@debbugs.gnu.org; Mon, 28 Mar 2016 07:22:57 -0400 Received: from [192.168.1.100] ([212.95.7.40]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MaV3V-1aQVYx3QWv-00KAfe; Mon, 28 Mar 2016 13:22:50 +0200 Message-ID: <56F91406.2080304@gmx.at> Date: Mon, 28 Mar 2016 13:22:46 +0200 From: martin rudalics MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:RwE0mmlmaeYUu9CcbTBWXj/Vh+d3V0pYSUJGx9anZK30eBbJ6y7 Q1CXbZCshQMJS9jHVnVSZYZTJ5TRQDGX7368cdBGHKVbTUTa21hOwyW3O7HwbPwEyb4Grbi patOaIadmvHa9m0ADG23GDvL4ST/fxzJA85fg6MLeuhtiHWxTLYyLaVpOFY2zSnb/Lq5e8f g40IUtf2J89sKkGkHlXZw== X-UI-Out-Filterresults: notjunk:1;V01:K0:GlT7aSV+wm0=:vZNPkIv3B0HtxGlpo6EA8x QGLTsvxTLCwo/j3JPOrE5P3TrT4EhuoZavIW/g5Jvns3yY4aGJluBmf+IcjhiH2AS15b66miz PrgX7NtDoCYazo70aXxmB0QFEwx4gnAYnsMxiypukAyvZS2odfw31F6nG2WWL1fJgQi6wXoxT 2jKTumymsEizw9RW2PEpTaXAB53yd00mob8H7P1zJy7+/9brxMoCoS5qn8M4AY8IUkWzY/slg 93TV1GW0bG/obsWstna9E3WXKxC4utf72CR6u6X3XJmXJgquVAZzHOGw5jecQmtmbd6gFcyab 0ml9Yx9zd972WsnevkUjsNtWMqdYi+cABg6G1q2I0P+BCDcSbHOV3t6EM289U3O7oANoHXZ0D Nt9aXs8A4XzvBRHwaiSJikFChEJ5hajq3Jrh/JYgFuLaPAUVRT2yyLEY95mgMQI1VUTuZdzp5 UvdAEJPQFXh31rH+ScsbWmRpsj5TQ88P6ye2RmB7yqJmSpc5VaCI2HqxDtxgDYnGYK94jzSUB TJByNRjOrSN3mcO/VDSkiYUpWIoGv6DI4b13kgJP4ireO782cs49elWdnoqmEs0ZJJBGLs9Q+ QqOEwwAfP4BZa2uhXPKNkwBlFnFADYa7gPLb5PrvZNucV3X/AwSAfQ8SdBN6SgJ3S+eJJqarj wMNoYpOIoMbr3M+kzn9RwBkKTyMwku2QIqgfj8aPAVld6tPIZFsatbrP+tUD0jpGfx3MgN1a0 GbIWOH0gfOn08S29CkUQBjgQm+uahNVg4tUGzc4RyxLGg7HHX5FzWD34JH4WGb14Ntp9A3IS3 0sI+JvGkbRQtEg1i/KqN7GMpoFF/Q== X-Spam-Score: -0.1 (/) 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.1 (/) > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens= fine. > > Type C-x 5 b > > - minibuffer shows > "Switch to buffer in other frame (default *GNU Emacs*):" > > I type "sam" [tab key for completion] > > - minibuffer says > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"= > > odd. If I remove the "sam" I just typed then type '?' to show the > buffer list, it opens a 2nd buffer at the bottom and shows > > Possible completions are: > *GNU Emacs* > *Messages* > *scratch* > > which does not show sample.txt, which is definitly there as I can see > it open in the buffer at the top. If, in this situation, you type C-x b, Emacs won't offer you sample.txt as completion either. Ditto for =E2=80=98switch-to-buffer-other-window=E2= =80=99. It's difficult to say what the correct behavior should be. I never use the buffer switching commands, so I have no preference. But I suppose that some people would complain if C-x b offered them the buffer already shown in the selected window as possible completion. So where would you draw the line? Basically, to switch to a buffer already shown in a window W, I wouldn't type C-x b but use C-x o to get there. To show the buffer shown in W in another window on the same frame, I'd type C-x 2 in W. To show the buffer shown in W in a window on another frame, I'd type C-x 5 2 in W. > Also, the behaviour is apparently broken if the current buffer/window = is split: > > a. open sample.txt > b. C-x 2 -- split window in 2, top and bottom > c. C-x 5 b -- try to get 2nd frame > d. sample.txt -- type in full filename in minibuffer > e. 2nd frame does *not* appear, cursor jumps to top of split window, > even if was originally in bottom. > > can reproduce? Why don't you just use C-x 5 2 here? Anyway, this happens because of the last two forms in (defvar display-buffer--other-frame-action '((display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . 0) (inhibit-same-window . t)) which OT1H inhibit using the selected window and OTOH, since we have no value for =E2=80=98reusable-frames=E2=80=99 to exclude the selected frame= from the list of reusable frames, allows reusing the window on the bottom. If people think that it's worth fixing this, we would probably have to invent a new alist entry like =E2=80=98inhibit-same-frame=E2=80=99. That= change might be obtrusive though, so I would not ardently recommend it for emacs-25. martin From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: jan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Mar 2016 08:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 23131@debbugs.gnu.org Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.145924052518175 (code B ref 23131); Tue, 29 Mar 2016 08:36:02 +0000 Received: (at 23131) by debbugs.gnu.org; 29 Mar 2016 08:35:25 +0000 Received: from localhost ([127.0.0.1]:42808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akp7U-0004j3-N3 for submit@debbugs.gnu.org; Tue, 29 Mar 2016 04:35:25 -0400 Received: from mail-yw0-f176.google.com ([209.85.161.176]:34947) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akp7S-0004iq-QY for 23131@debbugs.gnu.org; Tue, 29 Mar 2016 04:35:23 -0400 Received: by mail-yw0-f176.google.com with SMTP id g127so9805382ywf.2 for <23131@debbugs.gnu.org>; Tue, 29 Mar 2016 01:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=UVyhmI+4LHpf1hBMWlEj6NMqAjM4VI5VSHOEJkUowhY=; b=xVrmSGkQs2vGGv/HpYk2rvy/BoBUH9lfkHJDlVZCzsvi0TsrrbkpKddhYdXCfeZp4L ij8cPkgFA2bFpSKEqvSQYdI9yjVvCdvN5jTSUj426qVUKfwF1gwU/OCvIU/WiJ74XVK6 crRpzIF2dxnmlerPMiXE3LQO3d6439ZX4OL5WV1mXPFBPBUqOWWLpMBF8hH2QycTaKZO yb1JtyMd6f+sPh+e3nKmRJLDBjyMXWp41DyjWpUlyoQHlqKq4cMq3D1HEukYS7xyi8l5 OtGWSJHFhDm4ssehSFsIL89QYXkvxuJ+enfwmkt8sGwG4L//YhTHQURVXK/EIAec6gEZ jwdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=UVyhmI+4LHpf1hBMWlEj6NMqAjM4VI5VSHOEJkUowhY=; b=I/Mxx+8cqwRalEt/7/F+FC/zF5SJK7jEOikzO+VTemksIjuoZYzITiZg399mE2w8Sa B2E6HXReRTBWYn7eiHdmUNpBq+UxnR/bvjErFe6c3F23Bl4ZylthHQ71Hbsl6qpKL+3h lvolivPZ+UHBOXjMAcU8uKXRb52pVy+oNJc78Htt0c/Jqi/gSk4XtfqziMs283FMfNQ2 cKuiNWIGGeQ0WahAl9AoyB2x2dq4vCzKfs4DNfs/at397kOs6maxi/wUxkV9JVwLHgUw uI6WRodhXASiYMoRZ716W9bgVqTSFb8H5/kKfWHr2/e8lwIqeiy3EKMpq/rxToewjqqe xlqg== X-Gm-Message-State: AD7BkJLf1EXmPhXZVI/cp2aF1QxDkA9hg5xkpDSzW+9YhedXC4HEA+FSvoBOIHKBRhXCZI3XqADa2pjbpq7biA== MIME-Version: 1.0 X-Received: by 10.13.193.71 with SMTP id c68mr450917ywd.58.1459240517010; Tue, 29 Mar 2016 01:35:17 -0700 (PDT) Received: by 10.37.65.195 with HTTP; Tue, 29 Mar 2016 01:35:16 -0700 (PDT) In-Reply-To: <56F91406.2080304@gmx.at> References: <56F91406.2080304@gmx.at> Date: Tue, 29 Mar 2016 09:35:16 +0100 Message-ID: From: jan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: -0.0 (/) Hi Martin, please see below On 28/03/2016, martin rudalics wrote: > > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens > fine. > > > > Type C-x 5 b > > > > - minibuffer shows > > "Switch to buffer in other frame (default *GNU Emacs*):" > > > > I type "sam" [tab key for completion] > > > > - minibuffer says > > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]" > > > > odd. If I remove the "sam" I just typed then type '?' to show the > > buffer list, it opens a 2nd buffer at the bottom and shows > > > > Possible completions are: > > *GNU Emacs* > > *Messages* > > *scratch* > > > > which does not show sample.txt, which is definitly there as I can see > > it open in the buffer at the top. > > If, in this situation, you type C-x b, Emacs won't offer you sample.txt > as completion either. Ditto for =E2=80=98switch-to-buffer-other-window= =E2=80=99. I'd say that replication doesn't justify the behaviour. > It's > difficult to say what the correct behavior should be. I never use the > buffer switching commands, so I have no preference. But I suppose that > some people would complain if C-x b offered them the buffer already > shown in the selected window as possible completion. Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a feature: Emacs doesn't offer you a buffer that is already displayed in an existing window. This was introduced in Emacs 24." So it is new behaviour. Therefore: 1) was it introduced deliberately? If so, why? (if the code was the code made more complex by introducing a special case rather than simplifiying it, doubly why?) And: 2) this behaviour is not documented. My understanding is that documentation omissions are considered bugs. > So where would you draw the line? To me it's about interface usability and stability. Given the answer to point (1), I'd be in a much better position to know where to draw the line. > > Basically, to switch to a buffer already shown in a window W, I wouldn't > type C-x b but use C-x o to get there. To show the buffer shown in W in > another window on the same frame, I'd type C-x 2 in W. To show the > buffer shown in W in a window on another frame, I'd type C-x 5 2 in W. > > > Also, the behaviour is apparently broken if the current buffer/window = is > split: > > > > a. open sample.txt > > b. C-x 2 -- split window in 2, top and bottom > > c. C-x 5 b -- try to get 2nd frame > > d. sample.txt -- type in full filename in minibuffer > > e. 2nd frame does *not* appear, cursor jumps to top of split window, > > even if was originally in bottom. > > > > can reproduce? > > Why don't you just use C-x 5 2 here? Heh. I'd forgotten that! Thanks! But that doesn't change the original point of why the new behaviour. > Anyway, this happens because of > the last two forms in > > (defvar display-buffer--other-frame-action > '((display-buffer-reuse-window > display-buffer-pop-up-frame) > (reusable-frames . 0) > (inhibit-same-window . t)) > > which OT1H inhibit using the selected window and OTOH, since we have no > value for =E2=80=98reusable-frames=E2=80=99 to exclude the selected frame= from the list > of reusable frames, allows reusing the window on the bottom. > > If people think that it's worth fixing this, we would probably have to > invent a new alist entry like =E2=80=98inhibit-same-frame=E2=80=99. That= change might > be obtrusive though, so I would not ardently recommend it for emacs-25. I don't know much about emacs internals so I'll buy the point that a 'fix' would be unnecessary work for the dev team for this case. thanks jan > > martin > > From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: jan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Mar 2016 08:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 23131@debbugs.gnu.org Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.145924072418466 (code B ref 23131); Tue, 29 Mar 2016 08:39:02 +0000 Received: (at 23131) by debbugs.gnu.org; 29 Mar 2016 08:38:44 +0000 Received: from localhost ([127.0.0.1]:42813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akpAi-0004nl-AM for submit@debbugs.gnu.org; Tue, 29 Mar 2016 04:38:44 -0400 Received: from mail-yw0-f177.google.com ([209.85.161.177]:34042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akpAg-0004nZ-OU for 23131@debbugs.gnu.org; Tue, 29 Mar 2016 04:38:43 -0400 Received: by mail-yw0-f177.google.com with SMTP id h129so9931562ywb.1 for <23131@debbugs.gnu.org>; Tue, 29 Mar 2016 01:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=WHEjWN+zfsNAoGBM5Ll6qjRqlk3hjGBZ/9xbFV5xnc0=; b=aB6fSLxGwm8/DLAl28yjWs9b9aiPYS0bBQptOGGLjSThxv0NQYa6SbyuUci+P3q6bN zgIgSSpW6F7HjNm8OPuSSnLrU7NnZPPpH8ZMy5Zq5AN8tmzSG9f5J6J2IUF+Su1RLI+n t9qDDLvBpKOLHjXYsG7i5ln1XwFQHWmDmHdt2znibflmh+OFH5DiURJAFbSkC6O3R2TA i0HdSF93ov5mZw8ZfpODXu7SWuyhoGANI4OJiJtc6GZTbeMF3Jq2oU0blzv4Yli79KaF bE+yWCBRs++qgzdt09vrD+YMujndwClE3bDVGMRspevE20PpPbeoZ1z/+m6Z2Y3lunYE qGWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=WHEjWN+zfsNAoGBM5Ll6qjRqlk3hjGBZ/9xbFV5xnc0=; b=dAwv4VkFIj+MfKsg3JiSxrN3N6nrON7wmXgovYndI7jNAzM6XnJz5laIs/+10t0rBi o+50XGSZ+bLgmMPUsUfKQjQLHc8uyOtRjwlNOOhMJ1RXeC9CkN9beYvmye7h68wQoRsZ cIR4HAhp9L/kultP0lYlneYjJvUMeXK2vK6y3rPbegzsxD/cI1WsYn15zEpZq0t4wikt xIbrf7jN0zdjWEtTkxhfGGxbwIJT6TwJ7tSNE9FgjtYoK4P9wB58JQHDmnHt88VlP9b+ d2TLwzQhaFNOKbtdzeKK74nuA82XYTyETTtEe/sob++FHqCvOmIV20K1w8sG0zAnZuHq IoEQ== X-Gm-Message-State: AD7BkJKUAJFzyeyf00BnKAx1v4j2u4O2vcsb647zNlBdNvYT6YwAXhTbc3M4cC9gIGQgsNSyk5g//01kAI15pw== MIME-Version: 1.0 X-Received: by 10.37.91.134 with SMTP id p128mr416114ybb.69.1459240717370; Tue, 29 Mar 2016 01:38:37 -0700 (PDT) Received: by 10.37.65.195 with HTTP; Tue, 29 Mar 2016 01:38:37 -0700 (PDT) In-Reply-To: <56F91406.2080304@gmx.at> References: <56F91406.2080304@gmx.at> Date: Tue, 29 Mar 2016 09:38:37 +0100 Message-ID: From: jan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: -0.0 (/) Hi Martin, please see below On 28/03/2016, martin rudalics wrote: > > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens > fine. > > > > Type C-x 5 b > > > > - minibuffer shows > > "Switch to buffer in other frame (default *GNU Emacs*):" > > > > I type "sam" [tab key for completion] > > > > - minibuffer says > > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]" > > > > odd. If I remove the "sam" I just typed then type '?' to show the > > buffer list, it opens a 2nd buffer at the bottom and shows > > > > Possible completions are: > > *GNU Emacs* > > *Messages* > > *scratch* > > > > which does not show sample.txt, which is definitly there as I can see > > it open in the buffer at the top. > > If, in this situation, you type C-x b, Emacs won't offer you sample.txt > as completion either. Ditto for =E2=80=98switch-to-buffer-other-window= =E2=80=99. I'd say that replication of (arguably questionable) behaviour doesn't justify it. > It's > difficult to say what the correct behavior should be. I never use the > buffer switching commands, so I have no preference. But I suppose that > some people would complain if C-x b offered them the buffer already > shown in the selected window as possible completion. Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a feature: Emacs doesn't offer you a buffer that is already displayed in an existing window. This was introduced in Emacs 24." So it is new behaviour. Therefore: 1) was it introduced deliberately? If so, why? (if the code was the code made more complex by introducing a special case rather than simplifiying it, doubly why?) And: 2) this behaviour is not documented. My understanding is that documentation omissions are considered bugs. > So where would you draw the line? To me it's about interface usability and stability. Given the answer to point (1), I'd be in a much better position to know where to draw the line. > > Basically, to switch to a buffer already shown in a window W, I wouldn't > type C-x b but use C-x o to get there. To show the buffer shown in W in > another window on the same frame, I'd type C-x 2 in W. To show the > buffer shown in W in a window on another frame, I'd type C-x 5 2 in W. > > > Also, the behaviour is apparently broken if the current buffer/window = is > split: > > > > a. open sample.txt > > b. C-x 2 -- split window in 2, top and bottom > > c. C-x 5 b -- try to get 2nd frame > > d. sample.txt -- type in full filename in minibuffer > > e. 2nd frame does *not* appear, cursor jumps to top of split window, > > even if was originally in bottom. > > > > can reproduce? > > Why don't you just use C-x 5 2 here? Heh. I'd forgotten that! Thanks! But that doesn't change the original point of why the new behaviour. > Anyway, this happens because of > the last two forms in > > (defvar display-buffer--other-frame-action > '((display-buffer-reuse-window > display-buffer-pop-up-frame) > (reusable-frames . 0) > (inhibit-same-window . t)) > > which OT1H inhibit using the selected window and OTOH, since we have no > value for =E2=80=98reusable-frames=E2=80=99 to exclude the selected frame= from the list > of reusable frames, allows reusing the window on the bottom. > > If people think that it's worth fixing this, we would probably have to > invent a new alist entry like =E2=80=98inhibit-same-frame=E2=80=99. That= change might > be obtrusive though, so I would not ardently recommend it for emacs-25. I don't know much about emacs internals so I'll buy the point that a 'fix' would be unnecessary work for the dev team for this latter case. thanks jan > > martin > > From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Mar 2016 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: jan Cc: Juri Linkov , 23131@debbugs.gnu.org Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.145926442430523 (code B ref 23131); Tue, 29 Mar 2016 15:14:02 +0000 Received: (at 23131) by debbugs.gnu.org; 29 Mar 2016 15:13:44 +0000 Received: from localhost ([127.0.0.1]:43908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akvKx-0007wF-W8 for submit@debbugs.gnu.org; Tue, 29 Mar 2016 11:13:44 -0400 Received: from mout.gmx.net ([212.227.17.20]:52589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akvKv-0007w0-Pr for 23131@debbugs.gnu.org; Tue, 29 Mar 2016 11:13:42 -0400 Received: from [192.168.1.100] ([212.95.7.36]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MTjMy-1aKd3c31Um-00QWPF; Tue, 29 Mar 2016 17:13:32 +0200 Message-ID: <56FA9B97.5020807@gmx.at> Date: Tue, 29 Mar 2016 17:13:27 +0200 From: martin rudalics MIME-Version: 1.0 References: <56F91406.2080304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:PCLku/kO0PYd2HYX06Ve7/HAh4/3yf5fPK8JrAAz4okic2xOMKH uXZHJeTMIdLBctnhGcasY/13ceJbIWvtibGbZn6VyNeDLZ4isoxtgtPqk431huotsrwHr7H wUs+rXYLnP9vIff4JdttvDE7eIPb+f2LiGeb0hzgzD0B++LKcZU46cdeBHQUgNtvEBMV52H Sl7L1BeyuA9sqEcFwo2yQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Uam5JgYEZi4=:CdFkJXooyWCvu21Y4up2/0 DWPDdK5M3GZ/+Z0Mi6dYla5fwpTHF4QfewKV32i42caxfoBqEy/ZquIz2T+MyYsVArc3H2H75 7EDiU014UPqcQCf4/FEaKGq1acj2gZhA2Y26BruwuclJUA8oaQldVr/7D6LK7mmSbXIhcN1eW e0VaO0coCmLpVrkrCwzcg2aO+mtD1rLHUUUwi8ozVivX8lI6a1q/kTk0JK2cl1hlcI7e8XMSP inhKR7AG4Kfc3VGxQGiXY7V+lZSPBDKe8AOgDpUf00T+a6SCN3kwwvRn9rBY2WaNSV5TrJaug cSSIy+Jr4mX9MLulIAYFhHtGk+FcQ1Du2blXOLz/PXxGpM2IRwbeODWWct5fT+zHS0bDoJq6n Fgm6BibN1eTWWe6fV38lTKShu2d1AVhNpdIHI1NlgYeK9wM6m32iGO4UTr8rKp3KOIJjw/GGw CnFKFpE+7WOhn3v18UkcUo/n9/cV5AoZKA084+YCNtbZjKIpAFQZTO+hM0qvNrD3t+MA5U4i1 Ti3HIcIbPbT9K9DqjKeaoMvLT0M9kxlZxbWrM3mNhmxS12bKNi3c2Dif/amnelL41E6tr3aho +dU9FVhXQDEPpCoHg8UaCbiUpbjiONDtU99pfEUsA3Y8Te5hhTaNRYimLwt/GxxQPBP7DaBhd RuTPZ/x4EfmD8Pu4Qi1SF6f5jNOKADvVXC9TIa7kYDyAg24DKgqsbLU5j722YPNm5OEuPBVyV P7RmDpYFxXz0iZwMTL6nZk+tT+yagwmcN1tqVYfQ1wjvBNRzXOWNGT19z+NC3sJySEO6uhFCH Vkm27At32bpIInCFCwEnP0qUfAkpA== X-Spam-Score: -0.1 (/) 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.1 (/) >> If, in this situation, you type C-x b, Emacs won't offer you sample.t= xt >> as completion either. Ditto for =E2=80=98switch-to-buffer-other-wind= ow=E2=80=99. > > I'd say that replication of (arguably questionable) behaviour doesn't > justify it. We'll have to wait until the respective author(s) explain the reasons for the change. >> It's >> difficult to say what the correct behavior should be. I never use th= e >> buffer switching commands, so I have no preference. But I suppose th= at >> some people would complain if C-x b offered them the buffer already >> shown in the selected window as possible completion. > > Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a > feature: Emacs doesn't offer you a buffer that is already displayed in= > an existing window. This was introduced in Emacs 24." IIUC it was introduced in Emacs 23. > So it is new behaviour. Relatively so, since I can reproduce it with a seven years old build. If I'm not mistaken the change is by Juri Linkov from 2008-04-22. > Therefore: 1) was it introduced deliberately? If so, why? (if the code= > was the code made more complex by introducing a special case rather > than simplifiying it, doubly why?) > > And: 2) this behaviour is not documented. My understanding is that > documentation omissions are considered bugs. Juri, what do you think? martin From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Apr 2016 19:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: jan , 23131@debbugs.gnu.org Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.14595403499024 (code B ref 23131); Fri, 01 Apr 2016 19:53:02 +0000 Received: (at 23131) by debbugs.gnu.org; 1 Apr 2016 19:52:29 +0000 Received: from localhost ([127.0.0.1]:47578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am57M-0002LT-LX for submit@debbugs.gnu.org; Fri, 01 Apr 2016 15:52:28 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:44717 helo=homiemail-a23.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1am57L-0002LL-7W for 23131@debbugs.gnu.org; Fri, 01 Apr 2016 15:52:27 -0400 Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 1294E4B006F; Fri, 1 Apr 2016 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jurta.org; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=jurta.org; bh=m92Dqjy Wob21i7GLzx1p1pS7oo4=; b=hHAVGiVh6Q1PcF9+kcsgLhI7Rc7W5u5OqdimkoS m9ZcHC2o86AxOzhuYdMTTrNdlxOBeT2G/Utyit41ZSdUQu+n1Mue4EJULnw4bPl6 p5CyGO78rT6SXadf5Ak+h9nbThxG9sSPjV15PuXxO5r8yDvosRcrL0Wpz6G3SXaQ o6Kk= Received: from localhost.linkov.net (82.131.90.203.cable.starman.ee [82.131.90.203]) (Authenticated sender: jurta@jurta.org) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id BC3044B006D; Fri, 1 Apr 2016 12:52:24 -0700 (PDT) From: Juri Linkov Organization: LINKOV.NET References: <56F91406.2080304@gmx.at> <56FA9B97.5020807@gmx.at> Date: Fri, 01 Apr 2016 22:49:32 +0300 In-Reply-To: <56FA9B97.5020807@gmx.at> (martin rudalics's message of "Tue, 29 Mar 2016 17:13:27 +0200") Message-ID: <87a8ld6reb.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) 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: >>> If, in this situation, you type C-x b, Emacs won't offer you sample.txt >>> as completion either. Ditto for =?UTF-8?Q?=E2=80=98switch-to-buffer-other-window=E2=80=99.?= >> >> I'd say that replication of (arguably questionable) behaviour doesn't >> justify it. > > We'll have to wait until the respective author(s) explain the reasons > for the change. > >>> It's >>> difficult to say what the correct behavior should be. I never use the >>> buffer switching commands, so I have no preference. But I suppose that >>> some people would complain if C-x b offered them the buffer already >>> shown in the selected window as possible completion. >> >> Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a >> feature: Emacs doesn't offer you a buffer that is already displayed in >> an existing window. This was introduced in Emacs 24." > > IIUC it was introduced in Emacs 23. > >> So it is new behaviour. > > Relatively so, since I can reproduce it with a seven years old build. > If I'm not mistaken the change is by Juri Linkov from 2008-04-22. > >> Therefore: 1) was it introduced deliberately? If so, why? (if the code >> was the code made more complex by introducing a special case rather >> than simplifiying it, doubly why?) >> >> And: 2) this behaviour is not documented. My understanding is that >> documentation omissions are considered bugs. > > Juri, what do you think? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [69.163.253.7 listed in list.dnswl.org] 2.2 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3) [69.163.253.7 listed in bl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.5 (+) 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: >>> If, in this situation, you type C-x b, Emacs won't offer you sample.txt >>> as completion either. Ditto for =?UTF-8?Q?=E2=80=98switch-to-buffer-other-window=E2=80=99.?= >> >> I'd say that replication of (arguably questionable) behaviour doesn't >> justify it. > > We'll have to wait until the respective author(s) explain the reasons > for the change. > >>> It's >>> difficult to say what the correct behavior should be. I never use the >>> buffer switching commands, so I have no preference. But I suppose that >>> some people would complain if C-x b offered them the buffer already >>> shown in the selected window as possible completion. >> >> Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a >> feature: Emacs doesn't offer you a buffer that is already displayed in >> an existing window. This was introduced in Emacs 24." > > IIUC it was introduced in Emacs 23. > >> So it is new behaviour. > > Relatively so, since I can reproduce it with a seven years old build. > If I'm not mistaken the change is by Juri Linkov from 2008-04-22. > >> Therefore: 1) was it introduced deliberately? If so, why? (if the code >> was the code made more complex by introducing a special case rather >> than simplifiying it, doubly why?) >> >> And: 2) this behaviour is not documented. My understanding is that >> documentation omissions are considered bugs. > > Juri, what do you think? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.2 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3) [69.163.253.7 listed in bl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [69.163.253.7 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid >>> If, in this situation, you type C-x b, Emacs won't offer you sample.t= xt >>> as completion either. Ditto for =E2=80=98switch-to-buffer-other-wind= ow=E2=80=99. >> >> I'd say that replication of (arguably questionable) behaviour doesn't >> justify it. > > We'll have to wait until the respective author(s) explain the reasons > for the change. > >>> It's >>> difficult to say what the correct behavior should be. I never use th= e >>> buffer switching commands, so I have no preference. But I suppose th= at >>> some people would complain if C-x b offered them the buffer already >>> shown in the selected window as possible completion. >> >> Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a >> feature: Emacs doesn't offer you a buffer that is already displayed in >> an existing window. This was introduced in Emacs 24." > > IIUC it was introduced in Emacs 23. > >> So it is new behaviour. > > Relatively so, since I can reproduce it with a seven years old build. > If I'm not mistaken the change is by Juri Linkov from 2008-04-22. > >> Therefore: 1) was it introduced deliberately? If so, why? (if the code >> was the code made more complex by introducing a special case rather >> than simplifiying it, doubly why?) >> >> And: 2) this behaviour is not documented. My understanding is that >> documentation omissions are considered bugs. > > Juri, what do you think? This change was discussed here where you can see all arguments pro and co= ntra: http://thread.gmane.org/gmane.emacs.devel/93054/focus=3D95497 From unknown Wed Jun 25 02:10:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23131: switch-to-buffer-other-frame problem Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Jul 2021 14:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23131 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: martin rudalics , 23131@debbugs.gnu.org, jan Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.162627399628486 (code B ref 23131); Wed, 14 Jul 2021 14:47:01 +0000 Received: (at 23131) by debbugs.gnu.org; 14 Jul 2021 14:46:36 +0000 Received: from localhost ([127.0.0.1]:45655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3g9j-0007P7-QA for submit@debbugs.gnu.org; Wed, 14 Jul 2021 10:46:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3g9i-0007JO-Pq for 23131@debbugs.gnu.org; Wed, 14 Jul 2021 10:46:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pkNWnc0DDag2/dnCEimpDc5BlGo7EEQxbWRJidOXGAU=; b=r1P1gKo1jRe+yW+wxCef3TVxFN GhMZqyUgfPQBQhAZ5JOXZor6vTei6xzkx2fYQy/yDDe6BbHRU4gvl7JbaaZuvfOTJqEm6i6hW7B77 TUeu8qe0zlsUhSFjbqifFiIFJRrGAS1kKWgWOCI9tyVUWXb8RdYw7MGFtC272k57/teY=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3g9Z-0004ea-Bh; Wed, 14 Jul 2021 16:46:27 +0200 From: Lars Ingebrigtsen References: <56F91406.2080304@gmx.at> <56FA9B97.5020807@gmx.at> <87a8ld6reb.fsf@mail.linkov.net> X-Now-Playing: Nobukazu Takamura's _Music for the exhibition "Einheit"_: "(untitled)" Date: Wed, 14 Jul 2021 16:46:24 +0200 In-Reply-To: <87a8ld6reb.fsf@mail.linkov.net> (Juri Linkov's message of "Fri, 01 Apr 2016 22:49:32 +0300") Message-ID: <87eec1hs1r.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: >>> Therefore: 1) was it introduced deliberately? If so, why? (if the code >>> was the code made more complex by introducing a special case rather >>> than simplifiying it, doubly why?) >>> >>> And: 2 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Juri Linkov writes: >>> Therefore: 1) was it introduced deliberately? If so, why? (if the code >>> was the code made more complex by introducing a special case rather >>> than simplifiying it, doubly why?) >>> >>> And: 2) this behaviour is not documented. My understanding is that >>> documentation omissions are considered bugs. >> >> Juri, what do you think? > > This change was discussed here where you can see all arguments pro and contra: > http://thread.gmane.org/gmane.emacs.devel/93054/focus=95497 So I think this works as designed. We could perhaps mention `read-buffer-to-switch' in the interactive case in the doc strings, but I think that's a level of detail that'd just be counter-productive, so I'd rather not, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 10:46:40 2021 Received: (at control) by debbugs.gnu.org; 14 Jul 2021 14:46:40 +0000 Received: from localhost ([127.0.0.1]:45660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3g9o-0007TB-1w for submit@debbugs.gnu.org; Wed, 14 Jul 2021 10:46:40 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3g9n-0007NW-B5 for control@debbugs.gnu.org; Wed, 14 Jul 2021 10:46:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6TK0f06PAkLzQ/BM6PVhppTJE8xUihfg15jKerPl57Y=; b=sfIKjCUgoMNy9qj5YvVFCG1GJ9 +CnIaz0+e+rNsqr9SMchXPprpsUOSMT+XM09O67syL2I5ByJ0Z/mjIs+xq+doHiHEFaEW7dVtcQGY AgiW5EW/FvHTQrH4jxFSx2a8mC1lbtw6Cp+uq0f7jgPYaICThEsUPG4OW8YIr3L18Jcw=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3g9f-0004em-Mp for control@debbugs.gnu.org; Wed, 14 Jul 2021 16:46:33 +0200 Date: Wed, 14 Jul 2021 16:46:31 +0200 Message-Id: <87czrlhs1k.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #23131 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: close 23131 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) close 23131 quit