From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#27999: 26.0.50; delete-other-windows deletes side windows Date: Sat, 19 Aug 2017 11:11:40 +0200 Message-ID: <599800CC.40904@gmx.at> References: <87h8xkezr2.fsf@lylat> <59881D1A.80908@gmx.at> <87d187m60t.fsf@lylat> <598ADDC2.8010903@gmx.at> <87mv6wiqa6.fsf@lylat> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1503134002 4380 195.159.176.226 (19 Aug 2017 09:13:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Aug 2017 09:13:22 +0000 (UTC) Cc: 27999@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 19 11:13:18 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dizod-0000eP-G3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Aug 2017 11:13:11 +0200 Original-Received: from localhost ([::1]:34032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dizoj-0005Dp-RL for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Aug 2017 05:13:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dizoZ-0005BV-9g for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dizoU-000357-5v for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:13:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36463) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dizoU-00034z-28 for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dizoT-00025H-Pv for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Aug 2017 09:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27999 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.15031339277938 (code B ref -1); Sat, 19 Aug 2017 09:13:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 19 Aug 2017 09:12:07 +0000 Original-Received: from localhost ([127.0.0.1]:45144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1diznb-00023y-7k for submit@debbugs.gnu.org; Sat, 19 Aug 2017 05:12:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55595) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1diznZ-00023S-Qy for submit@debbugs.gnu.org; Sat, 19 Aug 2017 05:12:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1diznT-0002tK-7k for submit@debbugs.gnu.org; Sat, 19 Aug 2017 05:12:00 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:45888) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1diznT-0002tE-4b for submit@debbugs.gnu.org; Sat, 19 Aug 2017 05:11:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diznQ-0004mq-1L for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:11:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1diznI-0002rb-HT for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:11:55 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:52622) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1diznI-0002qw-77 for bug-gnu-emacs@gnu.org; Sat, 19 Aug 2017 05:11:48 -0400 Original-Received: from [192.168.1.100] ([46.125.249.118]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MaIsi-1dyTJQ2gJM-00JtRR; Sat, 19 Aug 2017 11:11:44 +0200 In-Reply-To: <87mv6wiqa6.fsf@lylat> X-Provags-ID: V03:K0:P8P5FESXnkJv89yASs4Y8dhJJXVfR/eU9A+cdvgcdbhvh2GzumG 3sTrmJxw06FsKJd0+U0QTM99+elcE8h9BEqXBTP0+E8uwK0anz0P27dGdSnF3P8TdWr322K 3rhLh0q8RjfEnP9UXDzhERGT6TItw6Ld4+QBfCcK4CJTt+p/U1KqTXPl5975KzGRtnZWAYc j+3p6Os65LzoPFuKcHT2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:tzpjLaVFdzI=:tJC1Ew45+PB3vv5wH0rJ44 Ghpdqbsib70/y7MMsVDh5/fHxlZNRk2e8EyJCtU9IvstKfWvlKM0ru2xAwRM2QCGAhsgjBQbt HD4J3138F5l+M4fMsrTBonrJ1KR9RA5JMIb3If1j55AdfcNkWAbO1+dbmgxCNzszj50bm8Re+ sQ+B3tp/ZrChOvxGg5tSelfzNQ1PQ9GP7IIO7BaMDNogwj1kWcwuv+jLoqH+o6aB1Iym45jFE DJ9rAMwDR4yjwcWCpNAOUf3Hl/J4npNUnsXxokDfmD/Gs7yVo5NSYb0FlET/VcawZPR+Geepv s0SdzLDKrnxcYgdaZmqX5c5K2asEeguLx0PXj2aD9/TEuih5ZAo7xDXdq9UtKtYGc1K9x2Cxn M5Uf8ExqtB/HwbHiaJ5ZyHgZaQMCHeiIETmdICdBaojDKhYetpnlHdZY1Ln5UrkLCLaWccGJ2 Y3GASFPpmCwwog7ayxi0RBmIjE7BHRQ5SbcKeVKNOaPUirYqRA/GiVYyBZUTEzpiPweFmIn3j e//whQfv2iaUitaOrDEwQZvgjvNdsWWDOJXatjbMERQTRZG48Lf7oJUS7cyBEWrj2ub7evLVi WVyKSrCWGHr65ixC+SL3FdMqI9zloJs86VShwU1QWYioLEewmIyKn9bVBKtFkh8UAMTnC1hWy bz3NrU+uZD7Lgm4qG9qDZUlWvNd3cmgbWM88PYhK2T5ROINpvjNHxqybUlOrfmIVuB4s2736P 8SOVLnrFVt6ifoUeDaaK9xuhwO2aWl3e4IlVIzTkTniPtTDhY1CEZAAT9Lr1kggB/mJKRVuC X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135911 Archived-At: > That sounds like a job for a different function. Wouldn't it make sens= e > for the default to have 'no-delete-other-window' by default, assuming > that more people want it than not (and perhaps only if there is a nice= > interface disabling it)? In the initial design there was no support to create side windows via =E2=80=98display-buffer=E2=80=99. Later on, I found the idea that a user= would have to make a "major" side window first overly confusing and added the =E2=80=98display-buffer-in-side-window=E2=80=99 action function. This, h= owever, means that the general =E2=80=98display-buffer=E2=80=99 conventions have to be = obeyed where anything special has to be specified via the ALIST argument as, for example, with =E2=80=98pop-up-frame-parameters=E2=80=99 or =E2=80=98windo= w-parameters=E2=80=99. So I'm still reluctant to make that change. >> Then we should probably care about the =E2=80=98no-other-window=E2=80= =99 parameter as >> well. BTW, a =E2=80=98no-delete-window=E2=80=99 parameter doesn't ex= ist yet - we would >> have to add it first. Currently, you have to set the =E2=80=98delete= -window=E2=80=99 >> parameter of the window to 'ignore. Also note that in general it's >> easier to just add a parameter than to first have one added and remov= e >> it afterwards. > > Right, I used #'ignore in my testing, but a separate `no-delete-window= ` > would be nice. We can easily add it but it's a matter of precedence: If a user specifies both =E2=80=98no-delete-window=E2=80=99 and =E2=80=98delete-win= dow=E2=80=99 which one prevails? > Regarding removing parameters, wouldn't it be easier to > set them to `nil' (when applicable), instead of outright removing them= ? We do set them to nil. That's what I had in mind when I used the term "remove". > Or perhaps there should just be a `remove-window-parameter' procedure > included. There's none because there is no such function for frame parameters either. Besides, I still don't know whether we somewhere test for the presence of a parameter with a given name instead of testing its value. > My main objection is that alists with many parameters are a bit annoyi= ng > to use for making side windows that aren't affected by > deletion/other-window commands. Here are a few alternatives (in no > particular order): > > (1) I think plists are a bit easier for users to work with, so perhaps= > an option to use one would be nice. `display-buffer-in-side-window' > could check to see if the user entered a plist, and could convert it t= o > the alist equivalent. We use alists in =E2=80=98display-buffer=E2=80=99 and I want to stick to = that convention. > (2) `display-buffer-in-side-windows' ^ > could instead use separate > arguments instead of the alist for the special symbols, including `sid= e' > and `slot'. This isn't as extensible, but it could be used only for > important arguments. This might create some confusion. =E2=80=98display-buffer-in-side-window= =E2=80=99 should behave like all other =E2=80=98display-buffer=E2=80=99 action func= tions. > (3) For similar parameters (e.g., deletion and accessing/moving), ther= e > could be a single argument/parameter which can have multiple values to= > toggle different behaviour. For example, there could be a symbol > `no-delete' with possible values `this' meaning "don't allow deletion > via `delete-window'", `other', meaning "don't allow deletion via > `delete-other-windows'", and `t', meaning don't delete via either. Or,= > if the idea of a side window that can't be deleted or accessed is comm= on > enough, then there should be a special symbol to denote that; e.g., > `intangible' could mean that the window can't be deleted or accessed v= ia > `other-window', with values optionally limiting this behaviour to > deletion or access. This again raises the question how to deal with the case where a user specifies both a =E2=80=98no-delete=E2=80=99 t and a =E2=80=98no-delete-o= ther-windows(s)=E2=80=99 nil parameter. > (4) There could be different procedures for different expectations. Fo= r > example, there could be a `display-tangible-buffer-in-side-window' tha= t > allows for deletion via "C-x 0" and "C-x 1", while the regular procedu= re > doesn't. This is probably the worst alternative. Probably. >>> The procedure mentions "a =E2=80=98window-parameter=E2=80=99 entry i= n ALIST", but it >>> doesn't mention the form it should be in. >> >> The doc-string of =E2=80=98display-buffer=E2=80=99 describes it as >> >> =E2=80=98window-parameters=E2=80=99 -- Value specifies an alist of = window >> parameters to give the chosen window. > > Oh, the docstring in `display-buffer-in-side-window' has a typo: it us= es > `window-parameter'. Thanks. It's a disease. Hopefully fixed now. > Yeah, terser names here lead to more ambiguity. Another possible way t= o > interpret these parameters is that when set, the window isn't affected= > or considered by the command. E.g., `no-delete-window' means "this > window is not affected by `delete-window'"; `no-delete-other-windows' > would mean "this window is not affected by `delete-other-windows'; > `no-other-window' means "this window is not considered by > 'other-window'. > > Under this interpretation, `no-delete-other-windows' makes more sense > than `no-delete-other-window'. Sounds plausible. Adopted now. > P.S. Section 28.19.3 uses the parameter `preserve-size', IIRC this is not a parameter but an argument for =E2=80=98fit-window-to-b= uffer=E2=80=99 which can also appear in the =E2=80=98display-buffer=E2=80=99 ALIST argum= ent. > while section > 28.29 uses `preserved-size'. This is indeed the corresponding parameter installed by =E2=80=98window-preserve-size=E2=80=99. martin