bug#27999: 26.0.50; delete-other-windows deletes side windows

[martin rudalics <rudalics@gmx.at>]

 > 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 the initial design there was no support to create side windows via
‘display-buffer’.  Later on, I found the idea that a user would have to
make a "major" side window first overly confusing and added the
‘display-buffer-in-side-window’ action function.  This, however, means
that the general ‘display-buffer’ conventions have to be obeyed where
anything special has to be specified via the ALIST argument as, for
example, with ‘pop-up-frame-parameters’ or ‘window-parameters’.  So I'm
still reluctant to make that change.

 >> 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.

We can easily add it but it's a matter of precedence: If a user
specifies both ‘no-delete-window’ and ‘delete-window’ 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 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.

We use alists in ‘display-buffer’ 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 `side'
 > and `slot'. This isn't as extensible, but it could be used only for
 > important arguments.

This might create some confusion.  ‘display-buffer-in-side-window’
should behave like all other ‘display-buffer’ action functions.

 > (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.

This again raises the question how to deal with the case where a user
specifies both a ‘no-delete’ t and a ‘no-delete-other-windows(s)’ nil
parameter.

 > (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.

Probably.

 >>> 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'.

Thanks.  It's a disease.  Hopefully fixed now.

 > 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'.

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 ‘fit-window-to-buffer’
which can also appear in the ‘display-buffer’ ALIST argument.

 > while section
 > 28.29 uses `preserved-size'.

This is indeed the corresponding parameter installed by
‘window-preserve-size’.

martin