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

[martin rudalics]

> 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