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: Mon, 22 Oct 2018 13:42:59 -0700 (PDT) Message-ID: <0f035e05-e04e-459c-b9a3-df1eb5542e65@default> References: <5BCD9331.6020203@gmx.at> <3c7bc9d6-2841-4f67-96ef-511af5237475@default> <5BCE21BD.80008@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 1540240879 10402 195.159.176.226 (22 Oct 2018 20:41:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Oct 2018 20:41:19 +0000 (UTC) To: martin rudalics , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 22 22:41:15 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 1gEh0g-0002Wr-Tv for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 22:41:11 +0200 Original-Received: from localhost ([::1]:37001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEh2n-0003OL-A9 for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 16:43:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEh2d-0003O3-BC for emacs-devel@gnu.org; Mon, 22 Oct 2018 16:43:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEh2Z-00056v-S3 for emacs-devel@gnu.org; Mon, 22 Oct 2018 16:43:11 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:52108) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gEh2Z-00053g-E7 for emacs-devel@gnu.org; Mon, 22 Oct 2018 16:43:07 -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 w9MKgwxY062369; Mon, 22 Oct 2018 20:43:02 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=fNIEGbl1HoKxEn3H7pYSPGsLpaD5/R5JTTYmHSsgk/I=; b=jFPDhtOVoImtAwFNk8pNQ4LwYIkuePjC3FVXLWdfYI4f3sR5EbB0gLT0Fr0nhC+3J9VH awVcfrF3WDua+qjJ+6oNpnBgbtC502lZ7se4PZkJfHxr9aMu0j6OUNGGMe5bIVPlCWqX CIclDl0t3cp8uXUEeqYA07cywoTJChXZKBaZ2c/+kwYOzrJyms8LG2Ck7GIunIoOMEyC uh7FDm6eSNl3bUt72qgDeB6TE9z/8k8m7V1lDIhb272fpXceVcHTK4QGfDcRiNdn0H/c uRZWSsbx8tKS81+rqzABH0l+kJu3R60X3Oh+k481UkWb/mDHWcENCeXnQVUASN2Ndzve 3A== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2n7vaps1pc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 20:43:02 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9MKh0Xf032507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 20:43:01 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9MKh0NX015906; Mon, 22 Oct 2018 20:43:00 GMT In-Reply-To: <5BCE21BD.80008@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-1810220175 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:230576 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'? Especially since there are other bookmark jumping commands that do not use another frame? The point of the thread that this discussion responds to was to add an other-frame bookmark jump command. We already have other bookmark-jump commands for the same window and for another window. And it is trivial to define your own bookmark jump command to do whatever you like that is special, whether for a specific bookmark, specific jump behavior, or whatever. In particular, predefined command `bookmark-jump', and some other jump commands, just invoke the general function `bookmark--jump-via', which accepts (surprise!) a DISPLAY-FUNCTION argument. That's the _only_ difference between some of those jump commands: the DISPLAY-FUNCTION argument passed. But since `bookmark-jump' itself accepts an optional DISPLAY-FUNCTION argument (which it just passes on to `bookmark--jump-via'), you can just as well call `bookmark-jump' instead of `bookmark--jump-via'. And BTW, that's what `bookmark-jump-other-window' does. And yes, if one prefers, `bookmark-jump-other-frame' could also be defined the same way (either of those ways). Or it could be defined by calling `bookmark-jump-other-window' while binding `pop-up-frames'. It doesn't matter to me which approach is taken for that. And it shouldn't matter to users - same behavior, AFAIK. > If this command forces the use of the > selected frame by binding some global variable instead of passing an > appropriate action argument, If the action argument passed just says to use another frame then the result is the same, no? It certainly seems the same in the question at hand, `bookmark-jump-other-frame'. In both cases the command "forces the use" of some particular display action. > it inhibits the user to customize its > behavior. Just like calling 'switch-to-buffer' inhibits the user to > pop to a buffer in another window or frame. A command that calls `switch-to-buffer' has different behavior from one that pops to a buffer in another window or frame. So what? We have different commands for these possibilities. Each of those commands "inhibits the user", providing only a specific buffer-display behavior. (But not `bookmark-jump' (or `bookmark--jump-via', which is not a command) - it doesn't inhibit using it to display a buffer anyway you like.) > > So there are multiple ways around your problem. > > Two of them are: (1) specify specific behavior for > > a specific bookmark and (2) use a different command. > > > > If you do want specific _buffers_ to be handled > > specially then you can of course have recourse to > > the general toolkit that is `display-buffer-alist'. > > No problem. >=20 > Unless the application overrides it. 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? Again, if you want specific display behavior you can get it. If you want one of the predefined behaviors you can have that too.