From: martin rudalics <rudalics@gmx.at>
To: Alex <agrambot@gmail.com>
Cc: 27999@debbugs.gnu.org
Subject: bug#27999: 26.0.50; delete-other-windows deletes side windows
Date: Sat, 19 Aug 2017 11:11:40 +0200 [thread overview]
Message-ID: <599800CC.40904@gmx.at> (raw)
In-Reply-To: <87mv6wiqa6.fsf@lylat>
> 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
next prev parent reply other threads:[~2017-08-19 9:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 5:02 bug#27999: 26.0.50; delete-other-windows deletes side windows Alex
2017-08-07 7:56 ` martin rudalics
2017-08-07 21:17 ` Alex
2017-08-09 10:02 ` martin rudalics
2017-08-18 20:17 ` Alex
2017-08-19 9:11 ` martin rudalics [this message]
2017-08-19 9:26 ` martin rudalics
2022-01-23 15:57 ` Lars Ingebrigtsen
2022-02-20 19:31 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=599800CC.40904@gmx.at \
--to=rudalics@gmx.at \
--cc=27999@debbugs.gnu.org \
--cc=agrambot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.