[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27999: 26.0.50; delete-other-windows deletes side windows
From: |
martin rudalics |
Subject: |
bug#27999: 26.0.50; delete-other-windows deletes side windows |
Date: |
Sat, 19 Aug 2017 11:11:40 +0200 |
> 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