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: Wed, 24 Oct 2018 19:40:02 +0200 Message-ID: <5BD0AE72.9060503@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> <5BCEE2B5.9090205@gmx.at> <83sh0wsnd6.fsf@gnu.org> <5BCF672A.4080605@gmx.at> <83k1m8scq9.fsf@gnu.org> <5BD03F18.1020100@gmx.at> <83h8hbs8ms.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: 7bit X-Trace: blaine.gmane.org 1540402749 15690 195.159.176.226 (24 Oct 2018 17:39:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2018 17:39:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 19:39:04 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 1gFN7Y-0003zP-Kc for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2018 19:39:04 +0200 Original-Received: from localhost ([::1]:49606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFN9f-0002Kb-7X for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2018 13:41:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFN94-0002KV-8H for emacs-devel@gnu.org; Wed, 24 Oct 2018 13:40:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFN90-0007J0-7C for emacs-devel@gnu.org; Wed, 24 Oct 2018 13:40:38 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:39057) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gFN8f-00079d-Ct; Wed, 24 Oct 2018 13:40:13 -0400 Original-Received: from [192.168.1.101] ([212.95.5.202]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LgeFd-1fln8W2FAT-00nvND; Wed, 24 Oct 2018 19:40:09 +0200 Original-Received: from [192.168.1.101] ([212.95.5.202]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LgeFd-1fln8W2FAT-00nvND; Wed, 24 Oct 2018 19:40:09 +0200 In-Reply-To: <83h8hbs8ms.fsf@gnu.org> X-Provags-ID: V03:K1:Mfc6w+/5fnE371inK9dQn73S3laKdyxu9unyxPxomE0LNMKQzXC sUyxtAUqquU7bcS62Xwq+ByZ+JD+Bmhu0FP4FRmSaAxfNiqAysctxSABV6m7eEmflM5zxrm 7ngyLI3xmbXklA2Iu7bnBWiKtpypV0pH9qbmY6JGssXDQc5dH4JZNkG463hiGg9rjhzs+5O jGI0mXMsQBLZq6Ym8dBzA== X-UI-Out-Filterresults: notjunk:1;V01:K0:l4I/sPv3KnY=:ebOvA4WCvj8H/kLDZ52o8O lJN/9yN5YtFtjS4xZ8w2jOie5bHsdDkcqLzCVlOSwvthxY5l4nn0TQkWONBBk71SxIBYiDCUM 8l5cI8kWoyHQMho/SBuv9B/v2/0jecHiCobT5j9oUbi5h4OzubJWMzWCONauLxCyiTbpc62zM y5Jp53uKTO2gpY0ka/El6aJIOfsbpiW5jAZ8AcJ5qkm3pvWk2y08Ep+k8M0qtroeRndMAqk7I 4avRaX7yPmhCS+tocm+FFCo2jZsL/oWIFwTG7V/DKyHGZbpQpf6PW11L5R8DbAN5ADECrCVGc xK45C/DMkRh/jiA/vKv4/4S1ppkE4aaDEipho61TOIoa7yu85S7Zw+ozjvpnQ0KseC8yiziHm k0AJ/MbBn7aIwR6suspGcTKAVoZZn2950+C0K0RF7QbyiBjHBonS0jMhS5HMOqw/pYhZ3EpcG B+PKtmlreIDiIh2kh9GAUrmtc+xP89U2YrEjcTOYw/Mvt9ZFJvMi2eEset9kx13M/JX0YbEpe KFJMCdAzylhb9dmN3sAXCeJ08yc5wRrmX9T0K/NYaziTnvHbN4EVGSh+FyRhXSE2TBmykLdBR vz+BeSsdHF7PACcp6LatikQY7mP7aJQOlLirbeKA+HnUi/UoUnY4zw/V++O8G7hoPHptceRqu 0eTZshd9mvzginAH6nnlXLI+0dDDzdwhxT4IG5ENzGTapL9VIoq0kPrv8BJacVaTERv0m6/LT 1frHHEyvtS9nLn+hbLwFJfq3M3sHwV/KCB4m6fKGruoiIYD56CwLHdHgAWi/V0MCbgaajIfM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:230638 Archived-At: > Just to clarify what I meant: I did NOT mean display-buffer-alist. I > meant something like this: > > find-dired is an interactive compiled function... > [...] > By default, display the buffer in the selected window; > NO-SELECT non-nil (interactively, prefix argument) means display the > buffer in a window other than the selected one instead. NO-SELECT non-nil implies that the window to show the buffer will not be selected which is probably not what the user wants here. > or > > By default, display the buffer in the selected window, but if > the value of `find-dired-no-select' is non-nil, display the > buffer in a window other than the selected one instead. > > This is our usual method of letting users tweak some minor aspects of > how a command works, and I see no reason why users would instead have > to construct action lists to do the same for commands that happen to > use display-buffer internally. Applications have the choice: Prescribe where and how buffers should be displayed or delegate that task to 'display-buffer'. 'ediff' uses the former approach through a number of options like, for example, 'ediff-split-window-function'. 'edebug' uses 'edebug-pop-to-buffer'. Users of the latter call 'pop-to-buffer' or 'display-buffer' directly. Both approaches are valid. 'switch-to-buffer' belongs to the first group unless the selected window is dedicated to some other buffer in which case 'switch-to-buffer' leaves the decision to 'pop-to-buffer' and we already have a hybrid approach. This is problematic and I always advocate against the use of 'switch-to-buffer' in code: The application should decide whether it wants one or the other. Still, if we want users to tweak only "some minor aspects of how a command works", the approach you sketch above is completely valid and I think that Juri's recent proposal to allow the directional choice of windows goes in the same direction and is even more universal. We can use 'display-buffer-overriding-action' for the prefix argument case and I am all for it. In either case, such a solution is not too distinct from Stephen Leake's 'other-frame-window' approach so we maybe should study that as well. But once an application directly or indirectly calls 'display-buffer' the latter's customizations may kick in and invalidate all assumptions about the window used. So if your NO-SELECT or Juri's directional effort fail, 'display-buffer' will inevitably rule the game. martin