From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: jan Newsgroups: gmane.emacs.bugs Subject: bug#23131: switch-to-buffer-other-frame problem Date: Tue, 29 Mar 2016 09:38:37 +0100 Message-ID: References: <56F91406.2080304@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1459240770 13378 80.91.229.3 (29 Mar 2016 08:39:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2016 08:39:30 +0000 (UTC) Cc: 23131@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 29 10:39:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1akpB9-0004Oo-9s for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Mar 2016 10:39:11 +0200 Original-Received: from localhost ([::1]:45184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akpB8-0000hR-Cz for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Mar 2016 04:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akpB4-0000hJ-Vn for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2016 04:39:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akpB0-0004ts-Kr for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2016 04:39:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akpB0-0004tn-Gg for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2016 04:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1akpB0-0004oK-CG for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2016 04:39:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 23131-submit@debbugs.gnu.org id=B23131.145924072418466 (code B ref 23131); Tue, 29 Mar 2016 08:39:02 +0000 Original-Received: (at 23131) by debbugs.gnu.org; 29 Mar 2016 08:38:44 +0000 Original-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 Original-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 Original-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== X-Received: by 10.37.91.134 with SMTP id p128mr416114ybb.69.1459240717370; Tue, 29 Mar 2016 01:38:37 -0700 (PDT) Original-Received: by 10.37.65.195 with HTTP; Tue, 29 Mar 2016 01:38:37 -0700 (PDT) In-Reply-To: <56F91406.2080304@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115686 Archived-At: 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 > >