From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Documenting buffer display Date: Tue, 23 Oct 2018 10:58:29 +0200 Message-ID: <5BCEE2B5.9090205@gmx.at> References: <5BCB1D82.3020108@gmx.at> <834ldgvjmj.fsf@gnu.org> <5BCB6DAE.30209@gmx.at> <83mur7tq4f.fsf@gnu.org> <5BCD92FF.8070905@gmx.at> <838t2qt79v.fsf@gnu.org> <5BCE21AC.6030904@gmx.at> <831s8hu6i8.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540285048 6538 195.159.176.226 (23 Oct 2018 08:57:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 08:57:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 23 10:57:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEsV5-0001VQ-LQ for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 10:57:19 +0200 Original-Received: from localhost ([::1]:38985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEsXC-00079g-9x for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 04:59:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEsWS-0006iX-Id for emacs-devel@gnu.org; Tue, 23 Oct 2018 04:58:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEsWP-0005Wj-0k for emacs-devel@gnu.org; Tue, 23 Oct 2018 04:58:44 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:39581) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gEsWO-0005Ir-MG; Tue, 23 Oct 2018 04:58:40 -0400 Original-Received: from [192.168.1.101] ([213.162.73.191]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrvWY-1fSnjR1tXS-013eMw; Tue, 23 Oct 2018 10:58:35 +0200 Original-Received: from [192.168.1.101] ([213.162.73.191]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrvWY-1fSnjR1tXS-013eMw; Tue, 23 Oct 2018 10:58:35 +0200 In-Reply-To: <831s8hu6i8.fsf@gnu.org> X-Provags-ID: V03:K1:+4Euctkf2HJlsX1wjgoDAdCxgg19orvx2V17GrT9cZbR9X1nWiB ePfIF6oRL0rClnE1xMqlNb11qJ+PPnOgRifQvMSWJyfN3GGslkdBy6oKttpHbefrG/tpi5C /lVPwa0DAb3hPQwViwtLdP5Wx93CHEKts1r39U8lscOA7RxeInwOW51cmt+IPlTJk5D2Lke FBDj5+7WiMB2a49M+DluA== X-UI-Out-Filterresults: notjunk:1;V01:K0:eV1TTnPwAAM=:Nrn1Qt039WQUgtQKCE/pNl DfRSXDBzF9sRja/Zn0G3GLr3sHHFMH3DsSy2GYCBqoatdbrjg46Wvd4rATVFHAMAV6+79UmOW 0qMHQXP+aPfQwfQlfr37l0GYwDqMzYwjL2XNMD/sMQzrZEcuL7/kp79NVmuwSghzteuel9aXO Rm8XBo+HOK6xBmAw+TikvkLnF+PJPy10SY4F+VUJ3RjNgQjoWBnNlgMAdJ5nEGvE6/qoY4fyg lQrJAPZCAI+K6gien3CyzG36cy2aPiefPYXj3T4CxnawbqLPMk0zQ1cuShbWxaHivilCsRPqw OXJImOeD/80X8FI7Sik04tuQ5Y7rJWG60m1h3O1JcvFLalxqKTnbDTkyqxMbtHLo32V90Lvi9 xDm88Z1u11OAhRliogBQaMdFd/lZ6dJaTUjj4i7fu+sjdvlTJ93L19rPwrxR+pbEESpBrrQIO MbbbuiI0slSotJn9/F2Q+xzszre0VfevF8xhjly00Ebgyl4tQuIjuMm3i9ShTB7oZtyE2FEQk v6UKjIXxI/J3icjK/DHV8IqwBcS/fTuX9NF5jBiZU3B+3Jk4TNl3MaUdacJuyNB2Moq9uZAQE 7O6n9pPYXxdtWtxMB4zlsNlSC//L7Ugb3qj+fmjsqFuhevrKelZZRQ92qp05s4CVw0NTG+jEe js2vHXbSepUhKl7waAHssnrm1gBdbDtk9iMb572cWhOqAfin6kqqbit0RzgS+OaYbRl5y0wcx rEYR3M49IU+LzkFHh54/w7CovNkqou+WmRtPSrS4kd7c9LTZ6ZZb5HJp3AosJlZnxJBGgSzQ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230577 Archived-At: > I must be missing something: using pop-to-buffer-SAME-window to > display a buffer in ANOTHER window? How can that make sense? Hysterical raisins. In the beginning, someone wrote a function called 'find-dired' to "Run `find' and go into Dired mode on a buffer of the output". In order to display that buffer, the author called 'switch-to-buffer' - probably because in his daily routine he preferred to continue working on that dired buffer right away in the selected window. In the end, Trevor Murphy writes that Like, I could imagine an alternate world where that call to `switch-to-buffer' could be replaced with something as heavy-handed as= =E2=80=A6 (pop-to-buffer (get-buffer-create "*Find*") '(display-buffer-sam= e-window (inhibit-same-window))) =E2=80=A6 so that Emacs would still try very hard to display the Find = buffer in the current window, but I could nevertheless override that by customizing `display-buffer-alist'. And that's where 'pop-to-buffer-same-window' kicks in by accomplishing _two_ things at the same time: It allows the author of 'find-dired' and its "normal" users to continue working as if nothing changed at all. And it allows users like Trevor to customize the way *Find* is displayed at their discretion. An earlier approach to provide such behavior was to add functions like 'find-dired-other-window' and 'find-dired-other-frame' maybe with appropriate key bindings. The shortcomings of that approach are: (1) The number of predefined functions to display a buffer is usually tripled. (2) The user may have to memorize key bindings for three functions instead of one. (3) These three functions still do not cover the entire spectrum of behaviors users want like showing the buffer on a specific side of the selected window or frame. With 'pop-to-buffer-same-window' all 'find-dired' does now is to _propose_ the selected window as the most suitable candidate for displaying *Find*. OTOH there's no more guarantee that *Find* will actually appear in the selected window. The ultimate decision of where *Find* will appear is left to the user. >> Which further means that a "not customized" caveat would be >> counterproductive here. > > All I meant was to add something like "by default" to the doc string. > I don't see how that could be wrong, all Stefan's advice > notwithstanding. > > We shouldn't shoot ourselves in the foot by being afraid that complex > enough customizations could invalidate the documentation. The doc-string of 'pop-to-buffer-same-window' is not useful for people who are happy with 'find-dired' behaving as it did before. Such users ideally will not even notice that something has changed and that they have to react to that change in some way. The doc-string of 'pop-to-buffer-same-window' is useful for two kinds of persons: (1) The author of 'find-dired' who now would be aware of the fact that *Find* will not be necessarily shown in the selected window. He will be warned by the word "preferably" in "Select buffer BUFFER in some window, preferably the same one." but he won't care about whether the default behavior avoids the selected window if its dedicated. In fact, he has to be prepared for the worst like *Find* popping up on a new frame or *Find* being displayed in the selected window despite the fact that it is dedicated to some other buffer. (2) Users who want to know how to _change_ the default behavior by customizing 'display-buffer-alist'. Such people typically want to show *Find* in some other window so they won't care about the dedicated status of the selected window either. I did not object to your changes when you made them because with Drew such objections inevitably lead to discussions why 'display-buffer' does it all wrong and why its earlier behavior was so much superior. But your change strengthens the view that 'display-buffer' behaves as requested by its caller. That view inevitably leads to confusion. >> Any explanation of what 'pop-to-buffer-same-window' does without >> referring the reader to 'display-buffer' is misleading, at the very >> least. > > I obviously disagree, as I did just that, and I object calling the > current text "misleading". Then why do we have all this dispute about 'display-buffer'? According to the majority of people because its documentation is confusing, wrong, incomplete, implicit, arcane or just bad. martin