From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `pop-up-frames' and binding/setting user options [was: Documenting buffer display] Date: Tue, 23 Oct 2018 11:01:16 -0700 (PDT) Message-ID: <939e2acd-f654-40c1-b595-4ec1fe1aab4d@default> References: <5BCD9331.6020203@gmx.at> <3c7bc9d6-2841-4f67-96ef-511af5237475@default> <5BCE21BD.80008@gmx.at> <0f035e05-e04e-459c-b9a3-df1eb5542e65@default> <5BCEE2C8.50008@gmx.at> <66b0ff55-af0d-42c0-80b1-87585e4c557f@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540317650 9802 195.159.176.226 (23 Oct 2018 18:00:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 18:00:50 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 23 20:00:46 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 1gF0yz-0002TD-60 for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 20:00:45 +0200 Original-Received: from localhost ([::1]:43627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF115-0006m8-Pp for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 14:02:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gF10t-0006gw-Dt for emacs-devel@gnu.org; Tue, 23 Oct 2018 14:02:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gF0zv-0001cJ-Si for emacs-devel@gnu.org; Tue, 23 Oct 2018 14:01:46 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:53788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gF0zv-0001IS-DS for emacs-devel@gnu.org; Tue, 23 Oct 2018 14:01:43 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9NHrtIV129935; Tue, 23 Oct 2018 18:01:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=pgLGcIJH5/+yO8dW9N/QDkM9C85mpQp29glMp78hor8=; b=Zf5nRT1bn9BzDRV9p845p+9pTbKcOmDAcgg4WO1LXR0k4Bek0Y79x82t33JWIwEZPv+2 uRWxHptjcbo36ybnm8MWHig6hN1h4Y9lX4bmzMDH6OK+cjl3ehHZO7lSoVjAIepnVa+V P32UQmiECJBzkHrDzO2B9zdVmSddlZpfA4gC+kKD3L4EOUsQ5GM92VcW4OXLZIYvVkrS mjL+hgjQbn0NqQE2l/YHSg2sHTeTwjhPdmj6F2B3/kXiIPwTbgE4VSisbocXrpjh1kQ8 Mbt6OuRW4LiRjdyLxJ4o8lUfWgAD+wICNz2MO+zeujxV/xUILMAvA5rEsLDyHGYAOziv gw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2n7vapxymd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 18:01:19 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9NI1HEx023697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 18:01:18 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9NI1HxN019459; Tue, 23 Oct 2018 18:01:17 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9055 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 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:230600 Archived-At: > > Sure, we both acknowledged that. But why would you > > choose to use an `other-frame' command for those > > specific bookmarks for which it is not TRT? That's > > the question. >=20 > Because the user doesn't want to have to think about it. So he always > uses the same key-binding and then configures display-buffer-alist to > adjust the behavior for those corner cases where another frame is not > the right destination. Nothing wrong with doing that. That's similar to using `special-display-buffer-names'. (Not the same, but similar.) There are alternative ways to get such an effect (including by doing the same thing for a different one of the bookmark-jump commands). We have same-window, other-window, and other-frame. Any of them could have its effect overridden in the way you suggest. And there are other approaches, including using a command that calls `bookmark-jump' passing a DISPLAY-FUNC argument what the user wants. That's much more trivial for a user to do than fiddling with `display-buffer-alist' to accomplish the same thing. None of this seems to me to be an argument against `pop-up-frames'. Nor does it seem to be an argument against having more than one bookmark-jump command, for a different display behaviors. See Eli's message today for reasons for the latter. More generally, see his msg for general arguments in favor of not promoting user customization of `display-buffer-alist' as the starting point for adjusting specific buffer display, especially command-specific actions. His arguments are mine too in this regard. And I add user conveniences such as `pop-up-frames' and `special-display-*' options to things that we should promote, not discourage, as user starting points for getting some specific buffer display and window selection behavior. `display-buffer-alist' is great to have. But specific this-window, other-window, and other-frame commands, as well as options such as `pop-up-frames' and `special-display-*', are better starting points for most users. I don't object to `display-buffer-alist'. I object to promoting its use to the exclusion of other, simpler ways of doing some of what it does. I object to _immediately_ throwing users down that rabbit hole. I recognize that `display-buffer' is a complex subject, and its complete and correct doc is bound to be somewhat hard to grasp. I don't have a problem with the doc being complete and correct - au contraire. What I object to is having the doc end up being _only_ that, or even pushing users to that as the starting point. As Eli said tactfully, `display-buffer-alist' should not be the _first resort_. Emacs provides some simpler ways to do some of what it offers, and those are better starting points, in general.