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

[Alex]

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