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 07:16:08 -0700 (PDT) Message-ID: <3c7bc9d6-2841-4f67-96ef-511af5237475@default> References: <5BCD9331.6020203@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 1540217750 30251 195.159.176.226 (22 Oct 2018 14:15:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Oct 2018 14:15:50 +0000 (UTC) To: martin rudalics , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 22 16:15: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 1gEazf-0007iH-5c for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 16:15:43 +0200 Original-Received: from localhost ([::1]:35493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEb1l-0001kh-M4 for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 10:17:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEb0P-0000yx-DL for emacs-devel@gnu.org; Mon, 22 Oct 2018 10:16:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEb0M-0003by-3j for emacs-devel@gnu.org; Mon, 22 Oct 2018 10:16:29 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:57322) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gEb0L-0003Wg-P6 for emacs-devel@gnu.org; Mon, 22 Oct 2018 10:16:26 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9ME06ea087855; Mon, 22 Oct 2018 14:16:16 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=riFTV7VICMaC8JOwqAVTiWqmiPKMWuJrP2a+TmjL4xM=; b=RQ3DRCjGAn9GbFLZXq965Fdf5G0NlCnZonieXGTJn+xuge2pLrlsW2uB8V8AZkBafYKe CPX3ssABoXvBUOlRVnOl5xJWwqQp5cJiADsHAIlzYj8myYmvHdMG/dAOhU1eVfl1P/HA AX1LjxXjhkI1xXO13ICJuM64+mEd7qAM/lGeWMBkx8r3yO30t8VVUHiBr/9rTkqFd8sE htogCZPYSmK9wW7zIWQPb1JiAshMAT5apoom9fd42VtAKpzDbrZZS5ukGdSGJsTxENbN hW33RARpoUdrwnrt+kbNf2/W7Ps9WXdUrJVG99fWNENaq7w/kjexAuzwAGfl1s9g8pM2 ow== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2n7ustxvf4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 14:16:16 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9MEG9fZ022298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 14:16:10 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9MEG9l6021818; Mon, 22 Oct 2018 14:16:09 GMT In-Reply-To: <5BCD9331.6020203@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=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-1810220122 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 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:230557 Archived-At: > > 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. >=20 > No. The call to that command might conflict with the user's intention > to usually pop up a new frame for most buffers but to not pop up a new > frame for some _specific buffer_ whose name is specified in > 'display-buffer-alist'. The binding of 'pop-up-frames' might defeat > precisely that latter intention (even if we do our best to avoid it). Users can do lots of things that conflict with each other. The point here is that it is a _user_ choice to use the command. If the command doc makes clear what its behavior is then I see no problem. Any user who does _not_ want a command that overrides particular user settings should simply not use that command. And it is pretty easy for a user to writer her own such commands. It is especially easy to write a command that provides non-nil `pop-up-frames' behavior. Granted, it is a bit more difficult to write a command that does that using `display-buffer-alist', and even more difficult to write a command that provides `pop-up-frames'-like behavior except for particular buffers. In such cases users can have recourse to `display-buffer-alist'. But for the simple case, `pop-up-frames' is handy. That's the point of it. =20 > > We create user options for user convenience. > > They are not something that should limit users. >=20 > Overriding the customization of 'display-buffer-alist' > does limit the user. A command that the user does not invoke does not override anything. She decides whether to invoke it. > > Did anyone tell programmers that they must always > > bind a variable instead of passing an argument to > > a function? I don't think so. >=20 > On the contrary we tell programmers to not bind a variable > and always pass an argument instead. I don't. I don't tell them to do any such thing _always_. Telling people that is black-&-white, and misleading. Emacs Lisp has dynamic binding (as well as lexical binding) for a reason. It's not C, and it's not Scheme. Not to mention that you cannot "always pass an argument" instead. Not without recoding the world, at least. See RMS's article for good, simple examples. Emacs Lisp is for Emacs - an interactive program. Sure, all of the advantages of lexical scoping are nice, but performance, for example, is in many instances not as important for Emacs as for other programming contexts. Optimization is, for Emacs, a nice-to-have, in general. Likewise, the better ability to reason about program behavior that lexical scoping brings. Likewise, the reduced funarg problems. But (1) we have lexical scoping now (and I, for one, am in favor of it being on by default, as in Common Lisp), and (2) if we really want solid semantic behavior (no funarg problems at all) then we should move to a purely functional, fully lazy language. I don't see #2 happening, and it need not. Emacs Lisp is a good language for Emacs. Emacs Lisp is a general programming language, but it is also specifically aimed at Emacs - human-scale, interactive use. > > 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. >=20 > Unless it's a specific bookmark the user wants to handle specifically. Maybe you meant "buffer" instead of "bookmark". (I often make that typo, in both directions.) But maybe you did mean bookmark. And the bookmark code gives you the possibility of treating specific bookmarks differently. And this code is for a _command_ whose job is specifically to pop to the bookmark in another frame. If you don't want that behavior for a particular bookmark then you won't use that command - you'll use a different command. 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. And even before doing that you might well get what you want just by using `special-display-buffer-names' or `special-display-regexps'. Those things don't pretend to do all that the `display-buffer-alist' toolkit does - that's not their aim. They are conveniences. Having them - in _addition_ to `display-buffer-alist' - is an advantage, not a disadvantage. > > 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. >=20 > Quite on the contrary. The only thing I appreciated > in that thread was what you wrote (and cited here). Glad it helped in some way. I'm looking for an Emacs that continues to allow conveniences such as `pop-up-frames' to cohabit peacefully with more powerful constructs such as `display-buffer-alist'. And thank you again for working on the doc for all of this - that's truly helpful. `display-buffer', like font-lock, keymaps, syntax tables, and a few other things in Emacs Lisp, is powerful and complicated. But it is more likely that an ordinary user will need to do the kinds of things that `display-buffer' offers than that she will need to fiddle with those other complex things (font-lock etc.). This means that it is good to help users a bit more with this doc, making it easy to understand. It also means, IMO, that it is good to promote, not discourage, simple conveniences such as `pop-up-frames' and `special-display-*'.