[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
From: |
Stefan Monnier |
Subject: |
bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist` |
Date: |
Sun, 10 Dec 2023 11:28:27 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> There's nothing wrong with having parameters and user options by the
> same name that affect the same functionality, but indeed usually the
> user option overrides the parameter, not the other way around. See,
> for example, the cursor-type option and frame parameter.
Usually the rule we follow is to obey the most specific setting.
In your example, we obey the (potentially buffer-local) variable in
preference to the frame-local parameter.
In my patch the choice is between the global variable (I've never seen
it set buffer-locally and I don't think the code would handle it "right"
if set buffer-locally) and the buffer/operation-specific parameter.
Also, contrary to the current situation where code let-binds the
variable to "impose" its choice over that of the user (which is hard to
undo/override), when code sets it via the new alist entry the user gets
a chance to override this override via `display-buffer-alist`.
The `display-buffer` action system is complex, but it is designed
specifically so as to allow the user to stay in control.
Stefan
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, Stefan Monnier, 2023/12/03
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, Eli Zaretskii, 2023/12/10
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, Stefan Monnier, 2023/12/10
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, martin rudalics, 2023/12/11
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, Stefan Monnier, 2023/12/11
- bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`, Stefan Monnier, 2023/12/16