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

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

[Alex]

I believe this is due to commit b8fd71d57 (C-x 1 works fine when
checking out its parent commit).

I tested using the following:

(display-buffer-in-side-window (get-buffer "*Messages*") '((side .
left)))

Executing "C-x 1" in Emacs 25.2 doesn't delete the *Messages* buffer,
but in master it does.

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

[martin rudalics]

 > I believe this is due to commit b8fd71d57 (C-x 1 works fine when
 > checking out its parent commit).

Right.

 > I tested using the following:
 >
 > (display-buffer-in-side-window (get-buffer "*Messages*") '((side .
 > left)))
 >
 > Executing "C-x 1" in Emacs 25.2 doesn't delete the *Messages* buffer,
 > but in master it does.

Please read Eli's complaints in the discussion of bug#24368

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24368

to understand why I made the change.  You now have to explicitly set the
'no-delete-other-window' parameter of a side window in order to preserve
it from being deleted.  This parameter works for any window, BTW.

I forgot to fix the doc-string of ‘delete-other-windows’ accordingly and
hopefully did that now.  Please have a look.

Thanks, martin

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

[Alex]

martin rudalics <rudalics@gmx.at> writes:

>> I tested using the following:
>>
>> (display-buffer-in-side-window (get-buffer "*Messages*") '((side .
>> left)))
>>
>> Executing "C-x 1" in Emacs 25.2 doesn't delete the *Messages* buffer,
>> but in master it does.
>
> Please read Eli's complaints in the discussion of bug#24368
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24368
>
> to understand why I made the change.  You now have to explicitly set the
> 'no-delete-other-window' parameter of a side window in order to preserve
> it from being deleted.  This parameter works for any window, BTW.
>
> I forgot to fix the doc-string of ‘delete-other-windows’ accordingly and
> hopefully did that now.  Please have a look.

Thanks, that makes it clearer.

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?

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.

The procedure mentions "a ‘window-parameter’ entry in ALIST", but it
doesn't mention the form it should be in. 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.

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.

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

[martin rudalics]

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

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

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.

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

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

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

martin

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

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

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

[martin rudalics]

 >  > while section
 >  > 28.29 uses `preserved-size'.
 >
 > This is indeed the corresponding parameter installed by
 > ‘window-preserve-size’.

A lie, obviously.  The parameter is called ‘window-preserved-size’.
Hopefully fixed now as well.

Thanks for the attentive reading, martin

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

[Lars Ingebrigtsen]

Alex <agrambot@gmail.com> writes:

> I believe this is due to commit b8fd71d57 (C-x 1 works fine when
> checking out its parent commit).
>
> I tested using the following:
>
> (display-buffer-in-side-window (get-buffer "*Messages*") '((side .
> left)))
>
> Executing "C-x 1" in Emacs 25.2 doesn't delete the *Messages* buffer,
> but in master it does.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this thread, I'm not quite sure whether the reported issue was
fixed or not.  But I'm unable to reproduce the problem in Emacs 28.  Are
you still seeing this problem in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Skimming this thread, I'm not quite sure whether the reported issue was
> fixed or not.  But I'm unable to reproduce the problem in Emacs 28.  Are
> you still seeing this problem in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no