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 07:13:52 -0700 (PDT) Message-ID: <66b0ff55-af0d-42c0-80b1-87585e4c557f@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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540303925 17871 195.159.176.226 (23 Oct 2018 14:12:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 14:12:05 +0000 (UTC) To: martin rudalics , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 23 16:12:01 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 1gExPb-0004Uh-KX for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 16:12:00 +0200 Original-Received: from localhost ([::1]:41827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gExRi-0002nI-1G for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2018 10:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gExRb-0002mz-Bz for emacs-devel@gnu.org; Tue, 23 Oct 2018 10:14:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gExRW-0004nI-DX for emacs-devel@gnu.org; Tue, 23 Oct 2018 10:14:03 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:60900) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gExRW-0004mo-6d for emacs-devel@gnu.org; Tue, 23 Oct 2018 10:13:58 -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 w9NEAZDd113027; Tue, 23 Oct 2018 14:13:55 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=LRMWcqvSbiiigAgVIhhWS1+Xc7eGjAMk4eMdFHiWoPc=; b=Zi+wDkiUBBANSuxCp+hGb4BXALS9hc+UPwt7T7laRBpBZLFoMngevpF24LdlAmwHDuER BRr0lZnlu5ShcfuL/xudrgzG6UBdaIUOOZqkEpf7xi33qWBpOjjTt11bXRh47yP2Whsi pfKI8nVTjKNfxnrHTVF6gINRfO3Th2wFGOPmXj7elOUjd8rtgC/h7CKRQkJsaqwggcOj sMoHyd+oWj1eIXwxWOYY8Uny70hswXz52kwQ09mWbEs8OKn+tnGqE79UDm4Yi2VFmdqF nUARRnq4ACTfOQYXepRpfi2LhxTF8QbcT47k3C71Tsmt4K8OmmzTROYHefjwImmd54bJ /Q== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2n7vapwg75-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 14:13:54 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9NEDsYX028030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 14:13:54 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9NEDrjt013938; Tue, 23 Oct 2018 14:13:53 GMT In-Reply-To: <5BCEE2C8.50008@gmx.at> 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=9054 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-1810230115 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:230583 Archived-At: > >> This command would be for usually popping up the bookmark in another > >> frame and the user would know that. However, for certain, specified > >> bookmarks the user might want to use the selected frame instead and > >> still use the same command. > > > > Why would someone choose to use an `other-frame' > > command to get some behavior other than `other-frame'? >=20 > Because for a user 'other-frame' may be TRT for most bookmarks but not > for a few specific ones. 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. > > Each of those specific bookmark jump commands > > specifies a particular buffer-display behavior > > (except `bookmark-jump', which accepts a behavior > > argument). Is that what you call the application > > overriding it? >=20 > No. It's the way the command specifies the behavior: If it does so by > binding a global variable, the result may be equivocal when the user > has customized 'display-buffer-alist'. If it does so by setting the > ACTION argument, the result is unequivocal. Specifics, please. If by equivocal you mean here that a user may not get what she expects sometimes then I imagine that the answer is to not use that approach in that case. So far, you haven't shown (AFAICT) any difference between binding `pop-up-frames' and imposing the same behavior by passing an ACTION argument. But if there is a difference in some case then I'd think the answer would be to use whichever of those approaches DTRT, and not the other. Is your argument against `pop-up-frames' only that of a maintainer - not wanting to bother maintaining support? Or is it that you see it as a bad thing for users to be able to use `pop-up-frames'? Saying that in some case (which I haven't seen demonstrated yet) it doesn't do the same thing that passing an equivalent argument does, does not invalidate its usefulness. At most it would be an argument for not using it in those hypothetical problematic cases.