unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex <agrambot@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 27999@debbugs.gnu.org
Subject: bug#27999: 26.0.50; delete-other-windows deletes side windows
Date: Fri, 18 Aug 2017 14:17:53 -0600	[thread overview]
Message-ID: <87mv6wiqa6.fsf@lylat> (raw)
In-Reply-To: <87h8xkezr2.fsf@lylat>

Sorry for not responding sooner.

martin rudalics <rudalics@gmx.at> 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 ‘no-other-window’ parameter as
> well.  BTW, a ‘no-delete-window’ parameter doesn't exist yet - we would
> have to add it first.  Currently, you have to set the ‘delete-window’
> 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 ‘window-parameter’ entry in ALIST", but it
>> doesn't mention the form it should be in.
>
> The doc-string of ‘display-buffer’ describes it as
>
>  ‘window-parameters’ -- 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 ‘display-buffer’ 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 ‘no-delete-other-window’ parameter should instead be
>> ‘no-delete-other-windows’, to match the plurality of
>> ‘delete-other-windows’. I made that mistake when first trying to set the
>> parameter.
>
> Suppose we added a ‘no-delete-window’ parameter: Its semantics would
> probably be to not delete this window.  Then a ‘no-delete-other-windows’
> 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 ‘no-other-window’
> 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'.





  reply	other threads:[~2017-08-18 20:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  5:02 bug#27999: 26.0.50; delete-other-windows deletes side windows Alex
2017-08-07  7:56 ` martin rudalics
2017-08-07 21:17   ` Alex
2017-08-09 10:02     ` martin rudalics
2017-08-18 20:17       ` Alex [this message]
2017-08-19  9:11         ` martin rudalics
2017-08-19  9:26           ` martin rudalics
2022-01-23 15:57 ` Lars Ingebrigtsen
2022-02-20 19:31   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mv6wiqa6.fsf@lylat \
    --to=agrambot@gmail.com \
    --cc=27999@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).