From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.bugs Subject: bug#27999: 26.0.50; delete-other-windows deletes side windows Date: Fri, 18 Aug 2017 14:17:53 -0600 Message-ID: <87mv6wiqa6.fsf@lylat> References: <87h8xkezr2.fsf@lylat> <59881D1A.80908@gmx.at> <87d187m60t.fsf@lylat> <598ADDC2.8010903@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 1503087552 27903 195.159.176.226 (18 Aug 2017 20:19:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Aug 2017 20:19:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 27999@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 18 22:19:08 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 1dinjW-0006uY-Lk for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Aug 2017 22:19:06 +0200 Original-Received: from localhost ([::1]:57405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dinjd-000859-8r for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Aug 2017 16:19:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dinjV-00084B-NA for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dinjS-0002rl-Ax for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:19:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35973) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dinjS-0002rL-6O for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dinjS-00051H-0S for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:19:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87h8xkezr2.fsf@lylat> Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Aug 2017 20:19: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.150308750519251 (code B ref -1); Fri, 18 Aug 2017 20:19:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 18 Aug 2017 20:18:25 +0000 Original-Received: from localhost ([127.0.0.1]:44654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dinir-00050R-Er for submit@debbugs.gnu.org; Fri, 18 Aug 2017 16:18:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dinip-00050B-9x for submit@debbugs.gnu.org; Fri, 18 Aug 2017 16:18:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dinii-0001CO-LI for submit@debbugs.gnu.org; Fri, 18 Aug 2017 16:18:17 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:58756) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dinii-0001CC-IC for submit@debbugs.gnu.org; Fri, 18 Aug 2017 16:18:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dinig-0007nD-Oy for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:18:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dinid-00014U-IQ for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:18:14 -0400 Original-Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]:33854) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dinid-00011R-BJ for bug-gnu-emacs@gnu.org; Fri, 18 Aug 2017 16:18:11 -0400 Original-Received: by mail-it0-x232.google.com with SMTP id f16so2405423itb.1 for ; Fri, 18 Aug 2017 13:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=E1IhyMMr/svzNxsiHG/egi6ZjU9NLRNfMaZjX5NPWJc=; b=l/yjPt0PFGMjXzhobGxyAsYbTYhJfAPwY9o785v0Y41wKqa96Q0fUYRA3lIFE3ScxC yQQsL5SXmtSDJvh5zkmlPp5Ms34PAC+QtQNi50Ni4ls0xiow/cl+3MKNcAywjrZvvkKY xqYUabvlTd9eqf255DfsDEWvqMJQBRzQ3EZowFPD2L0ITR7bZfV6xhDWXj73uUR5sRqu rQnM671qd4bZv+I3buUTWxuIdEecF+stxjnVpt8uOCoPAzTGyiuahLO0TpaVUDxGZkiM MKCFVN4M6ArSjttkF/+4448CnHQNsWtMn0YNOCUm61wC1QbFKV5xT9LgLYiGztjwSK39 AMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=E1IhyMMr/svzNxsiHG/egi6ZjU9NLRNfMaZjX5NPWJc=; b=LWuN7lg9GSwbj5qO9wIv+2O0euJbHtPRviEqUnjgjeNXIBV/5fK49/XfD6RuZKQoW4 5awoDfIdVkmeszQYJQaBDKMcM8YY8+j0/BA0YDqi3C2WTGNt8hk09zMSjXsqREufdIe3 N0mnJm/PM4M6dIK2nt1UtfT52pUxOnIQI+y+xxeZxip97mNGhUreyTXRbwx11FW+uV8I ynvuNUw72aEP9em30OavHwzFUivpsdvqz/sfNZdIc4fJV9ijn1iCACgrbcCyWl5dzMyw 2EHo21iDDW05517AX9AdVUm17aF/XO07QmeR+Wsl+kHnTjxDvejmKF9oJxzvuSZgBHse qeuQ== X-Gm-Message-State: AHYfb5gGjUsQ7/xlMgHx1WP+9mL+xo0gkMaA43iPZ25O/LXdb6jkyMLa 1w+NlHPFgKEjL3F9 X-Received: by 10.36.13.65 with SMTP id 62mr2801677itx.166.1503087488824; Fri, 18 Aug 2017 13:18:08 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id w135sm1041547itc.42.2017.08.18.13.18.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Aug 2017 13:18:07 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:135904 Archived-At: Sorry for not responding sooner. martin rudalics writes: >> I figure that for side windows, it would be more common to want the >> previous behaviour than not. Since if someone wanted to remove all side >> windows, one could use 'window-toggle-side-windows' instead, right? > > Right. But IIUC some people wanted side windows for the single purpose > to display a buffer on a chosen side of the frame. Once created, they > want the window to behave like any other ordinary window. They don't > get that because a side window cannot be made the single window of its > frame, cannot be split and the like. Still ... That sounds like a job for a different function. Wouldn't it make sense 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 any case, it would be nice to have a better interface for enabling >> (or disabling) this behaviour, rather than using 'set-window-parameter'. >> >> I'd like to suggest an additional (preferably terse) special symbol for >> the alist argument of 'display-buffer-in-side-window' that would inhibit >> window deletion either by delete-other-windows, delete-window, or both. > > 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 exist = yet - we would > have to add it first. Currently, you have to set the =E2=80=98delete-win= dow=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 remove > it afterwards. Right, I used #'ignore in my testing, but a separate `no-delete-window` would be nice. Regarding removing parameters, wouldn't it be easier to set them to `nil' (when applicable), instead of outright removing them? Or perhaps there should just be a `remove-window-parameter' procedure included. > There is an example in the Elisp manual section 28.19.3 Frame Layouts > with Side Windows. Could you read it first, tell me what is not clear > or clumsy to use. Then we could possibly come up with a better > solution. It's clear enough (though the formatting is a bit cluttered). My main objection is that alists with many parameters are a bit annoying 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 to the alist equivalent. (2) `display-buffer-in-side-windows' could instead use separate arguments instead of the alist for the special symbols, including `side' and `slot'. This isn't as extensible, but it could be used only for important arguments. (3) For similar parameters (e.g., deletion and accessing/moving), there 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 common 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 via `other-window', with values optionally limiting this behaviour to deletion or access. (4) There could be different procedures for different expectations. For example, there could be a `display-tangible-buffer-in-side-window' that allows for deletion via "C-x 0" and "C-x 1", while the regular procedure doesn't. This is probably the worst alternative. >> The procedure mentions "a =E2=80=98window-parameter=E2=80=99 entry in AL= IST", 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 uses `window-parameter'. >> I tried a few obvious forms, >> but none were applied. In any case, I believe it's still too >> inconvenient to list out the relevant parameters explicitly in this way. > > This should be improved since window parameters should be easily > specifiable in a =E2=80=98display-buffer=E2=80=99 alist not only for side= windows. > Please make a suggestion. The suggestion labelled (3) above would fit here the most. >> P.S. I believe the =E2=80=98no-delete-other-window=E2=80=99 parameter sh= ould instead be >> =E2=80=98no-delete-other-windows=E2=80=99, to match the plurality of >> =E2=80=98delete-other-windows=E2=80=99. I made that mistake when first t= rying to set the >> parameter. > > Suppose we added a =E2=80=98no-delete-window=E2=80=99 parameter: Its sema= ntics would > probably be to not delete this window. Then a =E2=80=98no-delete-other-w= indows=E2=80=99 > parameter's semantics would be to not delete any other windows when > invoked with this window selected. That's why I chose the term without > the "s". Arguably, this reasoning is broken by the =E2=80=98no-other-win= dow=E2=80=99 > parameter ... Yeah, terser names here lead to more ambiguity. Another possible way to 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'. P.S. Section 28.19.3 uses the parameter `preserve-size', while section 28.29 uses `preserved-size'.