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: `pop-up-frames' and binding/setting user options [was: Documenting buffer display] Date: Sun, 21 Oct 2018 09:10:20 -0700 (PDT) Message-ID: 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 1540138119 2546 195.159.176.226 (21 Oct 2018 16:08:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2018 16:08:39 +0000 (UTC) To: martin rudalics , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 21 18:08:35 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 1gEGHL-0000YI-9u for ged-emacs-devel@m.gmane.org; Sun, 21 Oct 2018 18:08:35 +0200 Original-Received: from localhost ([::1]:59576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEGJR-0006mj-RN for ged-emacs-devel@m.gmane.org; Sun, 21 Oct 2018 12:10:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEGJL-0006mU-7t for emacs-devel@gnu.org; Sun, 21 Oct 2018 12:10:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEGJG-0008UJ-7A for emacs-devel@gnu.org; Sun, 21 Oct 2018 12:10:39 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:36656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gEGJF-0008ME-VB for emacs-devel@gnu.org; Sun, 21 Oct 2018 12:10:34 -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 w9LGANrL152694; Sun, 21 Oct 2018 16:10:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=29nSc105YRqn7vXmByYi0dn7Sx8awa79z4RDg69em3A=; b=wqrHfudSxZS8ATZZe20TzdfxNgNGg2f0t0WFvP/rOYAOMBtfpa1R4yysVIh8fzadYj5t Wid7HmJGEZMIQB7VnFIhOwXtz3mt4OUk1ABjN5d8+u7fYisqO7Q5jNiEjkvbUjSRRVq9 qB50kIKomBuqTyTaJMtbWwrgP3d6RQynbSjc/KrxvlcgQjS99mkCIdMbwQ2CuFS4wqgf bwOkaNtt7Slnb1VToP9AbsBDf150g3VWS2qOKdZAuhgwyxjg1zv/1Qh2Sg9103ak621B CBWtc2MxCtBlQlvUZpBqaVMWwFcG4gHbP8MmBJYZjTXTqQB4NV6QWtLpx125MThU8rIF IQ== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2n7vapjyf4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 21 Oct 2018 16:10:27 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9LGALv0001576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 21 Oct 2018 16:10:22 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9LGALHf020953; Sun, 21 Oct 2018 16:10:21 GMT 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=9053 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-1810210150 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:230545 Archived-At: > > I disagree. If the behavior is documented in > > the command's doc string, as it should be, then > > the user is aware of it. Using a given command > > is a user choice. There is no reason to put on > > the hair shirt of not binding a user option in > > a user command, as long as the behavior is > > documented and the command ends always by > > restoring the user's preferred value for the > > option. >=20 > A user option has to be respected. A _user_ has to be respected. A user has a right to define or use a command that changes the value of a user option, whether that change is temporary (for the duration of the command) or stays in effect after the command. This should be obvious. Think toggle command, as the most obvious case. Emacs defines commands that toggle or otherwise set option values - and so do users define such commands. What makes that use case OK? (1) That's the very intention of the command: to change the option value. And (2) the command doc makes this quite clear to users. If you don't want to change the option value then you don't invoke the command. Nothing special here. And BTW, it makes perfect sense for a command that acts just like an other-window command, but uses other-frame instead of other-window, to bind `pop-up-frames'. That's precisely the meaning of `pop-up-frames': make other-window commands use other-frame. And such a command leaves the option value just as it was, when done. We create user options for user convenience. They are not something that should limit users. > If the designer of a command sees no other way to > have a command do what it is supposed to do than by > overriding a user option we have a severe design problem. I disagree with such must-not-be-any-other-way rigidity. There is no reason, IMO, why a command definition cannot change an option value, as long as the command doc makes that behavior clear. And in particular when that's the very raison d'etre for the command. As I said, I recognize that my opinion is maybe not the policy of Emacs (or perhaps of only an inflexible interpretation of the policy - dunno). Such a rigid policy is not wise, IMO. > 'display-buffer' has no design problem because > programmers can always ask it to do what they want > by specifying the ACTION argument appropriately. (No one has said that `display-buffer' has a design problem, AFAIK.) There is more than one way to do something in Emacs. Just because users can manipulate `display-buffer' to do something, that's no reason that they should be limited to using it directly. That there exists one way to do something is not a reason not to sometimes do it another way. Otherwise we would never create high-level convenience constructs and would just encourage users to directly use low-level building blocks. And, as that long-ago article from RMS about the utility (for Emacs) of dynamic binding shows, the fact that you can pass arguments to functions is no good substitute for being able to change the behavior of a function by dynamically binding a variable. Especially when the variable is well known to users and well documented. No one argues that global variables cannot make for debugging difficulties. They clearly couple code parts in a non-modular way. Lisp is not Haskell, and there are many, many ways in Lisp to couple code (and data) so that the behavior is not obvious and not just local. Just because you can do all kinds of things that couple code (and data) in Lisp is no reason that you should do so gratuitously and in silly ways. But it's also not a reason to forbid developers from making use of such possibilities when they make sense. That Emacs gives you plenty of rope that you can use to hang yourself is not a reason for it not to give you rope or to tell you not to use this or that rope it provides. > Telling programmers to bind a user option > instead is an invitation to bad design. Did anyone tell programmers that they must always bind a variable instead of passing an argument to a function? I don't think so. Who's making a black-&-white pronouncement of what everyone should always do or not do? If that's happening it's not happening in the direction of must-bind-variable. > > Secondly, users themselves define commands, > > and the ability to bind such a variable - > > whether it is an option or not, is very > > useful for users. >=20 > And when such users become programmers we get > our problems through the backdoor, compare the > recent "open bookmark in other frame" thread. What's your problem with that thread? I guess it's this code: (let ((pop-up-frames t)) (bookmark-jump-other-window bookmark)) Nothing could be simpler, clearer, or more elegant for a command that jumps to a bookmark in another frame, IMO. Telling someone that they must instead use `display-buffer' ACTION hoops to accomplish the same thing leads them down the garden path, on a wild goose chase, over the river & through the woods, and around Robin Hood's barn. IMO. But I didn't insist on that code. Far from it. I could see such a complaint coming from some quarters, which is why I suggested to "do the equivalent of [that code], or similar". And: Non-nil `pop-up-frames' just makes "other-window" commands use "other-frame". I wrote "the equivalent of this, or similar", because someone will perhaps say that there is a more "modern" way to do the same thing, involving a `display-buffer' ACTION or something... The above code DTRT, but someone might prefer a different formulation that does the same thing, or similar. Why did I write such qualification, even at the outset? Why anticipate the possibility of a knee-jerk reaction to binding a user option? Why indeed. Now I even wonder, since you pointed to that thread, whether my showing `pop-up-frames' there was perhaps a catalyst for your recent discouragement of `pop-up-frames' in the doc. (To reiterate: I do applaud your trying to clarify the buffer-display doc, other than the proposed change wrt `pop-up-buffers'.) To be extra clear: As I said there, I have no objection to someone writing the Emacs code for an other-frame bookmark-jump command in a way that is more round-about, in order to avoid using `pop-up-frames'. I personally wouldn't (and didn't) do that. I defined it in my code just as I wrote it there. But I make no pretense of imposing such a "bad design" style on Emacs. My wish is only for Emacs to not discourage it, and for Emacs to continue to support helpful constructs such as `pop-up-frames' and `special-display-regexps'. I still hope it will. And more generally, I wish that Emacs would not discourage, let alone forbid, the useful binding and setting of user options in commands. That it sometimes might not make sense for a command to change the value of an option is no reason to insist that it doesn't make sense in general.