bug#64619: [PATCH] Add toggle-window-dedicated command

bug#64619: [PATCH] Add toggle-window-dedicated command

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Tags: patch


It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

* lisp/window.el (toggle-window-dedicated): Add.
(window-prefix-map): Add C-x w d binding.


In GNU Emacs 29.0.92 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-07-10 built on
 igm-qws-u22796a
Repository revision: dd15432ffacbeff0291381c0109f5b1245060b1d
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --config-cache --with-x-toolkit=lucid
 --with-gif=ifavailable'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-toggle-window-dedicated-command.patch --]
[-- Type: text/patch, Size: 1814 bytes --]

From 2e8caf7d1f0a402568fac9e8767064a452499d60 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Fri, 14 Jul 2023 11:38:24 -0400
Subject: [PATCH] Add toggle-window-dedicated command

It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

* lisp/window.el (toggle-window-dedicated): Add.
(window-prefix-map): Add C-x w d binding.
---
 lisp/window.el | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/lisp/window.el b/lisp/window.el
index d91bbabc010..f884d9aaf16 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7463,6 +7463,20 @@ display-buffer-mark-dedicated
 The actual non-nil value of this variable will be copied to the
 `window-dedicated-p' flag.")
 
+(defun toggle-window-dedicated (&optional window interactive)
+  "Toggle whether WINDOW is dedicated.
+
+See `set-window-dedicated-p' for more details.  WINDOW defaults
+to the currently selected window."
+  (interactive "i\np")
+  (setq window (window-normalize-window window))
+  (if (window-dedicated-p window)
+      (progn
+        (set-window-dedicated-p window nil)
+        (when interactive (message "Window can now be used to display other buffers")))
+    (set-window-dedicated-p window 'dedicated)
+    (when interactive (message "Window will now display only its current buffer"))))
+
 (defconst display-buffer--action-function-custom-type
   '(choice :tag "Function"
 	   (const :tag "--" ignore) ; default for insertion
@@ -10746,6 +10760,7 @@ window-prefix-map
   "2" #'split-root-window-below
   "3" #'split-root-window-right
   "s" #'window-toggle-side-windows
+  "d" #'toggle-window-dedicated
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-- 
2.39.3

bug#64619: [PATCH] Add toggle-window-dedicated command

[Philip Kaludercic]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Tags: patch
>
>
> It's sometimes useful to interactively make certain windows dedicated.
> This allows a level of interactive control over which window
> display-buffer uses.

I think this sounds interesting, I think there is a lot that can be
improved when it comes to window management.

> * lisp/window.el (toggle-window-dedicated): Add.
> (window-prefix-map): Add C-x w d binding.
>
>
> In GNU Emacs 29.0.92 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.15.12, Xaw scroll bars) of 2023-07-10 built on
>  igm-qws-u22796a
> Repository revision: dd15432ffacbeff0291381c0109f5b1245060b1d
> Repository branch: emacs-29
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> System Description: CentOS Linux 7 (Core)
>
> Configured using:
>  'configure --config-cache --with-x-toolkit=lucid
>  --with-gif=ifavailable'
>
>>From 2e8caf7d1f0a402568fac9e8767064a452499d60 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 14 Jul 2023 11:38:24 -0400
> Subject: [PATCH] Add toggle-window-dedicated command
>
> It's sometimes useful to interactively make certain windows dedicated.
> This allows a level of interactive control over which window
> display-buffer uses.
>
> * lisp/window.el (toggle-window-dedicated): Add.
> (window-prefix-map): Add C-x w d binding.
> ---
>  lisp/window.el | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/lisp/window.el b/lisp/window.el
> index d91bbabc010..f884d9aaf16 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -7463,6 +7463,20 @@ display-buffer-mark-dedicated
>  The actual non-nil value of this variable will be copied to the
>  `window-dedicated-p' flag.")
>  
> +(defun toggle-window-dedicated (&optional window interactive)
> +  "Toggle whether WINDOW is dedicated.
> +
> +See `set-window-dedicated-p' for more details.  WINDOW defaults
> +to the currently selected window."

Shouldn't "interactive" be documented as well?  

> +  (interactive "i\np")

How about

  (interactive (list (window-normalize-window window) t))

> +  (setq window (window-normalize-window window))
> +  (if (window-dedicated-p window)
> +      (progn
> +        (set-window-dedicated-p window nil)
> +        (when interactive (message "Window can now be used to display other buffers")))
> +    (set-window-dedicated-p window 'dedicated)
> +    (when interactive (message "Window will now display only its current buffer"))))
> +
>  (defconst display-buffer--action-function-custom-type
>    '(choice :tag "Function"
>  	   (const :tag "--" ignore) ; default for insertion
> @@ -10746,6 +10760,7 @@ window-prefix-map
>    "2" #'split-root-window-below
>    "3" #'split-root-window-right
>    "s" #'window-toggle-side-windows
> +  "d" #'toggle-window-dedicated
>    "^ f" #'tear-off-window
>    "^ t" #'tab-window-detach
>    "-" #'fit-window-to-buffer

bug#64619: [PATCH] Add toggle-window-dedicated command

[Drew Adams]

Some minor comments.

> +  (if (window-dedicated-p window)
> +      (progn
> +        (set-window-dedicated-p window nil)
> +        (when interactive (message "Window can now be used to display other buffers")))
> +    (set-window-dedicated-p window 'dedicated)
> +    (when interactive (message "Window will now display only its current buffer"))))

1. Why _weakly_ dedicated?
2. Why not just this?

(let ((before  (window-dedicated-p window)))
  (set-window-dedicated-p window (not before))
  (when interactive
    (message "Window is %s dedicated to buffer %s"
             (if before "no longer" "now")
             (current-buffer))))

If someone might not know what it means for a
window to be dedicated, put that info in the
doc string, not in the message.

3. The toggle, as OP proposed it, imposes weak
dedication, and the toggle as I wrote it above
imposes strong dedication.  What if you want
a toggle that respects whatever non-nil FLAG
(weak or strong) might have already been used
for the window?

IOW, what if the window is dedicated to start
with, before you first use the toggle, and you
want to get back that same dedicated behavior
(weak or strong) when you toggle it back again?
The toggle (either definition) doesn't do that.

Shouldn't the doc make clear that the toggling
behavior is always between weak & undedicated
(OP version) or always between strong &
undedicated (my version, above)?  IOW, let a
user know that any original dedicated behavior
is lost, once you use the toggle.

Or if you want to let a user specify whether
to use weak or strong, maybe do that with a
prefix arg?                 

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Drew Adams <drew.adams@oracle.com> writes:

> Some minor comments.
>
>> +  (if (window-dedicated-p window)
>> +      (progn
>> +        (set-window-dedicated-p window nil)
>> +        (when interactive (message "Window can now be used to display other buffers")))
>> +    (set-window-dedicated-p window 'dedicated)
>> +    (when interactive (message "Window will now display only its current buffer"))))
>
> 1. Why _weakly_ dedicated?

AFAIK, the difference is that if you explicitly try to switch buffer
with e.g. C-x b, you succeed when the dedication is weak, and fail with
an error when the dedication is strong.  I find that if I explicitly hit
C-x b, I want to actually switch buffers in the current window, I never
want the switch to fail.  Making it fail seems useful for Lisp programs,
sometimes, but not so much interactive usage.

> 2. Why not just this?
>
> (let ((before  (window-dedicated-p window)))
>   (set-window-dedicated-p window (not before))
>   (when interactive
>     (message "Window is %s dedicated to buffer %s"
>              (if before "no longer" "now")
>              (current-buffer))))
>
> If someone might not know what it means for a
> window to be dedicated, put that info in the
> doc string, not in the message.

Will do.

> 3. The toggle, as OP proposed it, imposes weak
> dedication, and the toggle as I wrote it above
> imposes strong dedication.  What if you want
> a toggle that respects whatever non-nil FLAG
> (weak or strong) might have already been used
> for the window?
>
> IOW, what if the window is dedicated to start
> with, before you first use the toggle, and you
> want to get back that same dedicated behavior
> (weak or strong) when you toggle it back again?
> The toggle (either definition) doesn't do that.

That would be nice, but I don't see a way to do it.  At the same time, I
think it's probably fine for the user to explicitly choose whether they
want it to be weak or strong.  After all, this way it allows the user to
change the dedicated mode.

> Shouldn't the doc make clear that the toggling
> behavior is always between weak & undedicated
> (OP version) or always between strong &
> undedicated (my version, above)?  IOW, let a
> user know that any original dedicated behavior
> is lost, once you use the toggle.
>
> Or if you want to let a user specify whether
> to use weak or strong, maybe do that with a
> prefix arg?                 

Good point, I'll add a prefix arg for strong dedication.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Drew Adams]

> > 1. Why _weakly_ dedicated?
> 
> AFAIK, the difference is that if you explicitly try to switch buffer
> with e.g. C-x b, you succeed when the dedication is weak, and fail with
> an error when the dedication is strong.  I find that if I explicitly hit
> C-x b, I want to actually switch buffers in the current window, I never
> want the switch to fail.  Making it fail seems useful for Lisp programs,
> sometimes, but not so much interactive usage.

Thanks for providing your reasons/rationale.
That's the behavior you prefer, as one user.
Other users can prefer strong, not weak.  (But
I see, below, that you're considering providing
both.)

Let's not forget that "weak" dedication was
added as an additional, optional behavior,
decades after ordinary (aka strong) dedication
was in use.

> > 2. Why not just this?
> >
> > (let ((before  (window-dedicated-p window)))
> >   (set-window-dedicated-p window (not before))
> >   (when interactive
> >     (message "Window is %s dedicated to buffer %s"
> >              (if before "no longer" "now")
> >              (current-buffer))))
> >
> > If someone might not know what it means for a
> > window to be dedicated, put that info in the
> > doc string, not in the message.
> 
> Will do.

Maybe you won't want that toggling to `t' instead
of `dedicated', given your preference expressed
above?  (`not' nil returns `t'.)

> > 3. The toggle, as OP proposed it, imposes weak
> > dedication, and the toggle as I wrote it above
> > imposes strong dedication.  What if you want
> > a toggle that respects whatever non-nil FLAG
> > (weak or strong) might have already been used
> > for the window?
> >
> > IOW, what if the window is dedicated to start
> > with, before you first use the toggle, and you
> > want to get back that same dedicated behavior
> > (weak or strong) when you toggle it back again?
> > The toggle (either definition) doesn't do that.
> 
> That would be nice, but I don't see a way to do it.  At the same time, I
> think it's probably fine for the user to explicitly choose whether they
> want it to be weak or strong.  After all, this way it allows the user to
> change the dedicated mode.

Yes, that's where I was heading with that: not
easy to do, and we can just let users choose
which behavior they want.

> > Shouldn't the doc make clear that the toggling
> > behavior is always between weak & undedicated
> > (OP version) or always between strong &
> > undedicated (my version, above)?  IOW, let a
> > user know that any original dedicated behavior
> > is lost, once you use the toggle.
> >
> > Or if you want to let a user specify whether
> > to use weak or strong, maybe do that with a
> > prefix arg?
> 
> Good point, I'll add a prefix arg for strong dedication.

Thx.  (Though I'd prefer it the other way 'round. ;-))

bug#64619: [PATCH] Add toggle-window-dedicated command

[Spencer Baugh]

Philip Kaludercic <philipk@posteo.net> writes:
> Spencer Baugh <sbaugh@janestreet.com> writes:
>> +  (interactive "i\np")
>
> How about
>
>   (interactive (list (window-normalize-window window) t))

WINDOW isn't in scope of the interactive spec (AFAIK?), so we can't
process that window argument this way, we need to do it in the body.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Philip Kaludercic]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>> Spencer Baugh <sbaugh@janestreet.com> writes:
>>> +  (interactive "i\np")
>>
>> How about
>>
>>   (interactive (list (window-normalize-window window) t))
>
> WINDOW isn't in scope of the interactive spec (AFAIK?), so we can't
> process that window argument this way, we need to do it in the body.

Of course, what I meant to say was (window-normalize-window nil) or
(selected-window).

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 14 Jul 2023 11:38:59 -0400
> 
> It's sometimes useful to interactively make certain windows dedicated.
> This allows a level of interactive control over which window
> display-buffer uses.
> 
> * lisp/window.el (toggle-window-dedicated): Add.
> (window-prefix-map): Add C-x w d binding.

Adding Martin.  Martin, any comments?

bug#64619: [PATCH] Add toggle-window-dedicated command

[martin rudalics]

 >> * lisp/window.el (toggle-window-dedicated): Add.
 >> (window-prefix-map): Add C-x w d binding.
 >
 > Adding Martin.  Martin, any comments?

It should hardly harm anyone.  But what would be a typical scenario for
using it?  C-x b has 'switch-to-buffer-in-dedicated-window', C-x <left>
and friends probably should do the same.  Usually a window is marked as
dedicated to avoid that 'display-buffer' uses it.  In which case it
would likely be better to not mark the window as dedicated in the first
place - e.g. via a (dedicated . nil) entry in `display-buffer-alist'.

martin

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

martin rudalics <rudalics@gmx.at> writes:
>>> * lisp/window.el (toggle-window-dedicated): Add.
>>> (window-prefix-map): Add C-x w d binding.
>>
>> Adding Martin.  Martin, any comments?
>
> It should hardly harm anyone.  But what would be a typical scenario for
> using it?

When a window is not dedicated and one wants to make it dedicated, to
affect display-buffer.

> C-x b has 'switch-to-buffer-in-dedicated-window', C-x <left> and
> friends probably should do the same.  Usually a window is marked as
> dedicated to avoid that 'display-buffer' uses it.

Exactly.

> In which case it would likely be better to not mark the window as
> dedicated in the first place - e.g. via a (dedicated . nil) entry in
> `display-buffer-alist'.

Yes, this is about making windows dedicated, not making them not
dedicated.  I implemented it as a toggle only because that seems nicer
to a user who might otherwise make a window dedicated on accident and
not know how to undo it.

bug#64619: [PATCH] Add toggle-window-dedicated command

[martin rudalics]

 > Yes, this is about making windows dedicated, not making them not
 > dedicated.  I implemented it as a toggle only because that seems nicer
 > to a user who might otherwise make a window dedicated on accident and
 > not know how to undo it.

But how would our user know which of his windows are dedicated?
'display-buffer' won't tell because it silently ignores them.

martin

bug#64619: [PATCH] Add toggle-window-dedicated command

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]


OK, this patch adds support for making the buffer strongly dedicated
with a prefix argument, and also adds an indicator to the mode line of
whether the current window is dedicated (which seems useful even if we
don't apply the toggle part of this patch).

I wonder if we should support clicking on the mode line indicator to
turn off dedicated status?  The tricky thing is that the mode line
indicator disappears when the window isn't dedicated, so there's no way
to turn it back *on* using the mouse.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-toggle-window-dedicated-command-and-mode-line-wi.patch --]
[-- Type: text/x-patch, Size: 4209 bytes --]

From 6346388d0992ad78b42e79590db60f2f337b0b88 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Fri, 14 Jul 2023 11:38:24 -0400
Subject: [PATCH] Add toggle-window-dedicated command and
 mode-line-window-dedicated

It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

Additionally, when a window is dedicated (even without this new
command) it can affect display-buffer behavior in ways which may be
unexpected for users.  Let's display the window dedicated status in
the mode-line to help indicate what's going on.

* lisp/window.el (toggle-window-dedicated): Add.
(window-prefix-map): Add C-x w d binding.
* lisp/bindings.el (mode-line-window-control): Add.
(mode-line-window-dedicated): Add.
(standard-mode-line-format): Insert mode-line-window-dedicated.
---
 lisp/bindings.el | 22 ++++++++++++++++++++++
 lisp/window.el   | 28 ++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 0a0fef1b564..a570b5d6a7b 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -298,6 +298,27 @@ mode-line-frame-identification
 ;;;###autoload
 (put 'mode-line-frame-identification 'risky-local-variable t)
 
+(defun mode-line-window-control ()
+  "Compute mode line construct for window dedicated state.
+Value is used for `mode-line-window-dedicated', which see."
+  (cond
+   ((eq (window-dedicated-p) t)
+   '(:propertize
+     " D"
+     help-echo "Window is strongly dedicated to current buffer"
+     mouse-face 'mode-line-highlight))
+   ((window-dedicated-p)
+   '(:propertize
+     " d"
+     help-echo "Window is dedicated to current buffer"
+     mouse-face 'mode-line-highlight))
+   (t "")))
+
+(defvar mode-line-window-dedicated '(:eval (mode-line-window-control))
+  "Mode line construct to describe the current window.")
+;;;###autoload
+(put 'mode-line-window-dedicated 'risky-local-variable t)
+
 (defvar-local mode-line-process nil
   "Mode line construct for displaying info on process status.
 Normally nil in most modes, since there is no process to display.")
@@ -678,6 +699,7 @@ mode-line-end-spaces
 	            'mode-line-modified
 	            'mode-line-remote)
               'display '(min-width (5.0)))
+             'mode-line-window-dedicated
 	     'mode-line-frame-identification
 	     'mode-line-buffer-identification
 	     "   "
diff --git a/lisp/window.el b/lisp/window.el
index d91bbabc010..259c1e679ac 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7463,6 +7463,33 @@ display-buffer-mark-dedicated
 The actual non-nil value of this variable will be copied to the
 `window-dedicated-p' flag.")
 
+(defun toggle-window-dedicated (&optional window flag interactive)
+  "Toggle whether WINDOW is dedicated.
+
+See `set-window-dedicated-p' for more details.  WINDOW defaults
+to the currently selected window.  FLAG defaults to
+`dedicated' (weak dedication) or `t' (strong dedication) with a
+prefix argument.  If INTERACTIVE is non-nil, will print a message
+about the dedication status of the window afterwards."
+  (interactive "i\nP\np")
+  (setq window (window-normalize-window window))
+  (setq flag (cond
+              ((consp flag) t)
+              ((null flag) 'dedicated)
+              (t flag)))
+  (if (window-dedicated-p window)
+      (set-window-dedicated-p window nil)
+    (set-window-dedicated-p window flag))
+  (when interactive
+    (message "Window is %s dedicated to buffer %s"
+             (let ((status (window-dedicated-p window)))
+               (cond
+                ((null status) "no longer")
+                ((eq status t) "now strongly")
+                (t "now")))
+             (current-buffer))
+    (force-mode-line-update)))
+
 (defconst display-buffer--action-function-custom-type
   '(choice :tag "Function"
 	   (const :tag "--" ignore) ; default for insertion
@@ -10746,6 +10773,7 @@ window-prefix-map
   "2" #'split-root-window-below
   "3" #'split-root-window-right
   "s" #'window-toggle-side-windows
+  "d" #'toggle-window-dedicated
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-- 
2.39.3

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Spencer Baugh <sbaugh@janestreet.com> writes:
> OK, this patch adds support for making the buffer strongly dedicated
> with a prefix argument, and also adds an indicator to the mode line of
> whether the current window is dedicated (which seems useful even if we
> don't apply the toggle part of this patch).

Any thoughts on this patch?

bug#64619: [PATCH] Add toggle-window-dedicated command

[Philip Kaludercic]

sbaugh@catern.com writes:

> Spencer Baugh <sbaugh@janestreet.com> writes:
>> OK, this patch adds support for making the buffer strongly dedicated
>> with a prefix argument, and also adds an indicator to the mode line of
>> whether the current window is dedicated (which seems useful even if we
>> don't apply the toggle part of this patch).
>
> Any thoughts on this patch?

I just tried it out and it works as advertised.  The only question is if
a NEWS entry should be added, or if it is worth mentioning it in the
manual?

(P.S. I have had issues sending this message, but perhaps I might have
done something wrong as well: "smtpmail-send-it: Sending failed: 450
4.1.2 <sbaugh@catern.com>: Recipient address rejected: Domain not found")

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Philip Kaludercic <philipk@posteo.net> writes:

> sbaugh@catern.com writes:
>
>> Spencer Baugh <sbaugh@janestreet.com> writes:
>>> OK, this patch adds support for making the buffer strongly dedicated
>>> with a prefix argument, and also adds an indicator to the mode line of
>>> whether the current window is dedicated (which seems useful even if we
>>> don't apply the toggle part of this patch).
>>
>> Any thoughts on this patch?
>
> I just tried it out and it works as advertised.  The only question is if
> a NEWS entry should be added, or if it is worth mentioning it in the
> manual?

Yes, I think definitely a NEWS entry is warranted, if only because it
adds an indicator the mode line.  But I wanted to settle the format
before writing it.

> (P.S. I have had issues sending this message, but perhaps I might have
> done something wrong as well: "smtpmail-send-it: Sending failed: 450
> 4.1.2 <sbaugh@catern.com>: Recipient address rejected: Domain not found")

That's because my DNS/mail server just crashed :)

bug#64619: [PATCH] Add toggle-window-dedicated command

[Philip Kaludercic]

sbaugh@catern.com writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> sbaugh@catern.com writes:
>>
>>> Spencer Baugh <sbaugh@janestreet.com> writes:
>>>> OK, this patch adds support for making the buffer strongly dedicated
>>>> with a prefix argument, and also adds an indicator to the mode line of
>>>> whether the current window is dedicated (which seems useful even if we
>>>> don't apply the toggle part of this patch).
>>>
>>> Any thoughts on this patch?
>>
>> I just tried it out and it works as advertised.  The only question is if
>> a NEWS entry should be added, or if it is worth mentioning it in the
>> manual?
>
> Yes, I think definitely a NEWS entry is warranted, if only because it
> adds an indicator the mode line.  But I wanted to settle the format
> before writing it.

I think it is fine the way it is right now.

>> (P.S. I have had issues sending this message, but perhaps I might have
>> done something wrong as well: "smtpmail-send-it: Sending failed: 450
>> 4.1.2 <sbaugh@catern.com>: Recipient address rejected: Domain not found")
>
> That's because my DNS/mail server just crashed :)

Testing :)

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> sbaugh@catern.com writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> sbaugh@catern.com writes:
>>>
>>>> Spencer Baugh <sbaugh@janestreet.com> writes:
>>>>> OK, this patch adds support for making the buffer strongly dedicated
>>>>> with a prefix argument, and also adds an indicator to the mode line of
>>>>> whether the current window is dedicated (which seems useful even if we
>>>>> don't apply the toggle part of this patch).
>>>>
>>>> Any thoughts on this patch?
>>>
>>> I just tried it out and it works as advertised.  The only question is if
>>> a NEWS entry should be added, or if it is worth mentioning it in the
>>> manual?
>>
>> Yes, I think definitely a NEWS entry is warranted, if only because it
>> adds an indicator the mode line.  But I wanted to settle the format
>> before writing it.
>
> I think it is fine the way it is right now.

OK, added a NEWS entry and information in the manual.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-toggle-window-dedicated-command-and-mode-line-wi.patch --]
[-- Type: text/x-patch, Size: 6674 bytes --]

From dc02ad0891c3a832617d6b234bd30a0bc8f8ef69 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Sat, 19 Aug 2023 16:01:54 -0400
Subject: [PATCH] Add toggle-window-dedicated command and
 mode-line-window-dedicated

It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

Additionally, when a window is dedicated (even without this new
command) it can affect display-buffer behavior in ways which may be
unexpected for users.  Let's display the window dedicated status in
the mode-line to help indicate what's going on.

* doc/emacs/windows.texi (Displaying Buffers): Add information about
dedicated windows and toggle-window-dedicated.
* etc/NEWS: Announce the mode-line-window-dedicated and
toggle-window-dedicated.
* lisp/window.el (toggle-window-dedicated): Add.
(window-prefix-map): Add C-x w d binding.
* lisp/bindings.el (mode-line-window-control): Add.
(mode-line-window-dedicated): Add.
(standard-mode-line-format): Insert mode-line-window-dedicated.
---
 doc/emacs/windows.texi | 16 ++++++++++++++++
 etc/NEWS               | 14 ++++++++++++++
 lisp/bindings.el       | 22 ++++++++++++++++++++++
 lisp/window.el         | 28 ++++++++++++++++++++++++++++
 4 files changed, 80 insertions(+)

diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
index e4abdef76be..f24ffc20464 100644
--- a/doc/emacs/windows.texi
+++ b/doc/emacs/windows.texi
@@ -411,6 +411,22 @@ Displaying Buffers
 window on some other frame to display the desired buffer.  Several of
 these commands are bound in the @kbd{C-x 5} prefix key.
 
+  Sometimes, a window is ``dedicated'' to its current buffer.
+@code{display-buffer} will avoid reusing dedicated windows most of the
+time.  This is indicated by a ``d'' in the mode line.  A window can
+also be strongly dedicated, which prevents any changes to what buffer
+that window displays; this is indicated by a ``D'' in the mode line.
+
+Usually, dedicated windows are used to display specialized buffers,
+but dedication can sometimes be useful to interactively control
+@code{display-buffer}'s window choices.
+
+@kindex C-x w d
+@findex toggle-window-dedicated
+  Toggle whether the current window is dedicated to the current
+buffer.  With a prefix argument, make the window strongly dedicated
+instead.
+
 @menu
 * Window Choice::   How @code{display-buffer} works.
 * Temporary Displays::   Displaying non-editable buffers.
diff --git a/etc/NEWS b/etc/NEWS
index 3cfc36e10da..6368d640fb7 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -92,6 +92,20 @@ plus, minus, check-mark, start, etc.
 The 'tool-bar-position' frame parameter can be set to 'bottom' on all
 window systems other than Nextstep.
 
++++
+** 'd' in the mode line now indicates that the window is dedicated.
+Windows have always been able to be dedicated to a specific buffer;
+see 'window-dedicated-p'.  Now the mode line indicates the dedicated
+status of a window, with 'd' appearing in the mode line if a window is
+dedicated and 'D' if the window is strongly dedicated.
+
++++
+** New command 'toggle-window-dedicated'.
+This makes it easy to interactively mark a specific window as
+dedicated, so it won't be reused by 'display-buffer'.  This can be
+useful for complicated window setups.  It is bound to 'C-x w d'
+globally.
+
 ** cl-print
 *** You can expand the "..." truncation everywhere.
 The code that allowed "..." to be expanded in the *Backtrace* should
diff --git a/lisp/bindings.el b/lisp/bindings.el
index f1a75b080be..b751fed22ce 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -298,6 +298,27 @@ mode-line-frame-identification
 ;;;###autoload
 (put 'mode-line-frame-identification 'risky-local-variable t)
 
+(defun mode-line-window-control ()
+  "Compute mode line construct for window dedicated state.
+Value is used for `mode-line-window-dedicated', which see."
+  (cond
+   ((eq (window-dedicated-p) t)
+   '(:propertize
+     " D"
+     help-echo "Window is strongly dedicated to current buffer"
+     mouse-face 'mode-line-highlight))
+   ((window-dedicated-p)
+   '(:propertize
+     " d"
+     help-echo "Window is dedicated to current buffer"
+     mouse-face 'mode-line-highlight))
+   (t "")))
+
+(defvar mode-line-window-dedicated '(:eval (mode-line-window-control))
+  "Mode line construct to describe the current window.")
+;;;###autoload
+(put 'mode-line-window-dedicated 'risky-local-variable t)
+
 (defvar-local mode-line-process nil
   "Mode line construct for displaying info on process status.
 Normally nil in most modes, since there is no process to display.")
@@ -675,6 +696,7 @@ mode-line-end-spaces
 	            'mode-line-modified
 	            'mode-line-remote)
               'display '(min-width (5.0)))
+             'mode-line-window-dedicated
 	     'mode-line-frame-identification
 	     'mode-line-buffer-identification
 	     "   "
diff --git a/lisp/window.el b/lisp/window.el
index d91bbabc010..259c1e679ac 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7463,6 +7463,33 @@ display-buffer-mark-dedicated
 The actual non-nil value of this variable will be copied to the
 `window-dedicated-p' flag.")
 
+(defun toggle-window-dedicated (&optional window flag interactive)
+  "Toggle whether WINDOW is dedicated.
+
+See `set-window-dedicated-p' for more details.  WINDOW defaults
+to the currently selected window.  FLAG defaults to
+`dedicated' (weak dedication) or `t' (strong dedication) with a
+prefix argument.  If INTERACTIVE is non-nil, will print a message
+about the dedication status of the window afterwards."
+  (interactive "i\nP\np")
+  (setq window (window-normalize-window window))
+  (setq flag (cond
+              ((consp flag) t)
+              ((null flag) 'dedicated)
+              (t flag)))
+  (if (window-dedicated-p window)
+      (set-window-dedicated-p window nil)
+    (set-window-dedicated-p window flag))
+  (when interactive
+    (message "Window is %s dedicated to buffer %s"
+             (let ((status (window-dedicated-p window)))
+               (cond
+                ((null status) "no longer")
+                ((eq status t) "now strongly")
+                (t "now")))
+             (current-buffer))
+    (force-mode-line-update)))
+
 (defconst display-buffer--action-function-custom-type
   '(choice :tag "Function"
 	   (const :tag "--" ignore) ; default for insertion
@@ -10746,6 +10773,7 @@ window-prefix-map
   "2" #'split-root-window-below
   "3" #'split-root-window-right
   "s" #'window-toggle-side-windows
+  "d" #'toggle-window-dedicated
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-- 
2.41.0

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Sat, 19 Aug 2023 20:02:35 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh@janestreet.com>, Eli Zaretskii <eliz@gnu.org>,
> 	martin rudalics <rudalics@gmx.at>, Drew Adams <drew.adams@oracle.com>,
> 	64619@debbugs.gnu.org
> 
> OK, added a NEWS entry and information in the manual.

Thanks, a few comments, mainly to the documentation, below.

> +  Sometimes, a window is ``dedicated'' to its current buffer.

Please add here a cross-reference to where dedicated windows are
described in the ELisp manual.  (This is our standard style of
documentation: whenever we mention a feature or terminology explained
elsewhere, we add a cross-reference there, unless one is already
available nearby.)

I would also add a @cindex entry here:

  @cindex dedicated window

> +@code{display-buffer} will avoid reusing dedicated windows most of the
> +time.  This is indicated by a ``d'' in the mode line.

And here there should be a cross-reference to where the mode line is
described.

>                                                        A window can
> +also be strongly dedicated, which prevents any changes to what buffer
> +that window displays;

"...prevents any changes to the buffer displayed in the window" is
easier to comprehend.

> +Usually, dedicated windows are used to display specialized buffers,
> +but dedication can sometimes be useful to interactively control
> +@code{display-buffer}'s window choices.

This text is not very useful.  How about adding an example or two for
when the user may wish to make a window dedicated, or make a dedicated
window not dedicated?  Then this command will make much more sense.

> +
> +@kindex C-x w d
> +@findex toggle-window-dedicated
> +  Toggle whether the current window is dedicated to the current
                        ^^^^^^^
"selected", not "current".  Or maybe "currently-selected".

We should also make changed in the section the describes the mode
line, to include this indication there.

> ++++
> +** 'd' in the mode line now indicates that the window is dedicated.
> +Windows have always been able to be dedicated to a specific buffer;
> +see 'window-dedicated-p'.  Now the mode line indicates the dedicated
> +status of a window, with 'd' appearing in the mode line if a window is
> +dedicated and 'D' if the window is strongly dedicated.

This should tell where on the mode line this indication will be shown.

> +(defun mode-line-window-control ()
> +  "Compute mode line construct for window dedicated state.
> +Value is used for `mode-line-window-dedicated', which see."
> +  (cond
> +   ((eq (window-dedicated-p) t)
> +   '(:propertize
> +     " D"
> +     help-echo "Window is strongly dedicated to current buffer"
> +     mouse-face 'mode-line-highlight))
> +   ((window-dedicated-p)
> +   '(:propertize
> +     " d"
> +     help-echo "Window is dedicated to current buffer"
> +     mouse-face 'mode-line-highlight))
> +   (t "")))

Why not allow toggling the state by a mouse click, like we do with the
buffer-writable indication?

And the tooltip text is too long, I think.  I suggest to use shorter
text:

   Window dedicated to its buffer
   Window strongly dedicated to its buffer

> @@ -675,6 +696,7 @@ mode-line-end-spaces
>  	            'mode-line-modified
>  	            'mode-line-remote)
>                'display '(min-width (5.0)))
> +             'mode-line-window-dedicated
>  	     'mode-line-frame-identification
>  	     'mode-line-buffer-identification
>  	     "   "

Why not add this to the group with the min-width property (and enlarge
that to 6.0)?  That way, we prevent annoying horizontal movement of
the rest of the mode-line display when toggling the state.

> +(defun toggle-window-dedicated (&optional window flag interactive)
> +  "Toggle whether WINDOW is dedicated.
> +
> +See `set-window-dedicated-p' for more details.  WINDOW defaults
> +to the currently selected window.  FLAG defaults to
> +`dedicated' (weak dedication) or `t' (strong dedication) with a
> +prefix argument.  If INTERACTIVE is non-nil, will print a message
> +about the dedication status of the window afterwards."

This is a command, so the doc string must be detailed enough and
user-friendly.  Sending the user to read a doc string of another
function is acceptable only if that other function is also a command
(so that the doc string doesn't include too many technicalities), and
if the description is very complicated in its user-facing parts.  I
don't think this is the case.  My suggestion is to use the following
doc string instead:

    Toggle whether WINDOW is dedicated to its current buffer.

  WINDOW must be a live window and defaults to the selected one.
  If FLAG is t (interactively, the prefix argument), make the window
  \"strongly\" dedicated to its buffer.  FLAG defaults to a non-nil,
  non-t value, and is passed to `set-window-dedicated-p', which see.
  If INTERACTIVE is non-nil, print a message describing the dedication
  status of WINDOW, after toggling it.  Interactively, this argument is
  always non-nil.

  When a window is dedicated to its buffer, `display-buffer' will avoid
  displaying another buffer in it, if possible.  When a window is
  strongly dedicated to its buffer, changing the buffer shown in the
  window will usually signal an error.

  See the info node `(elisp)Dedicated Windows' for more details.

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]


Applied Eli's comments and added support for customizing which flag
toggle-window-dedicated sets by default.  New patch attached.

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Sat, 19 Aug 2023 20:02:35 +0000 (UTC)
>> Cc: Spencer Baugh <sbaugh@janestreet.com>, Eli Zaretskii <eliz@gnu.org>,
>> 	martin rudalics <rudalics@gmx.at>, Drew Adams <drew.adams@oracle.com>,
>> 	64619@debbugs.gnu.org
>> +
>> +@kindex C-x w d
>> +@findex toggle-window-dedicated
>> +  Toggle whether the current window is dedicated to the current
>                         ^^^^^^^
> "selected", not "current".  Or maybe "currently-selected".

Selected seems more common than currently-selected so went with that.

>> @@ -675,6 +696,7 @@ mode-line-end-spaces
>>  	            'mode-line-modified
>>  	            'mode-line-remote)
>>                'display '(min-width (5.0)))
>> +             'mode-line-window-dedicated
>>  	     'mode-line-frame-identification
>>  	     'mode-line-buffer-identification
>>  	     "   "
>
> Why not add this to the group with the min-width property (and enlarge
> that to 6.0)?  That way, we prevent annoying horizontal movement of
> the rest of the mode-line display when toggling the state.

Hm, I tried doing that, but maybe I don't understand min-width, because
there's still horizontal movement of the mode-line when I toggle it on
and off.  I tried various combinations of strings, but they all had this
behavior, maybe I'm doing something obviously wrong?

Also, if we make it fixed-size in this way, should we display "-"
instead of nothing when the window is not dedicated? Or just an empty
space?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-toggle-window-dedicated-command-and-mode-line-wi.patch --]
[-- Type: text/x-patch, Size: 10130 bytes --]

From b92b7dcb9e8dcb017e69462f8f7e580dba2b8fce Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Sat, 19 Aug 2023 16:01:54 -0400
Subject: [PATCH] Add toggle-window-dedicated command and
 mode-line-window-dedicated

It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

Additionally, when a window is dedicated (even without this new
command) it can affect display-buffer behavior in ways which may be
unexpected for users.  Let's display the window dedicated status in
the mode-line to help indicate what's going on.

* doc/emacs/windows.texi (Displaying Buffers): Add information about
dedicated windows and toggle-window-dedicated.
* doc/emacs/screen.texi (Mode Line): Add information about the window
dedicated indicator.
* etc/NEWS: Announce mode-line-window-dedicated and
toggle-window-dedicated.
* lisp/window.el (toggle-window-dedicated): Add.
(window-prefix-map): Add C-x w d binding.
* lisp/bindings.el (mode-line-window-control): Add.
(mode-line-window-dedicated): Add.
(standard-mode-line-format): Insert mode-line-window-dedicated.
---
 doc/emacs/screen.texi  |  8 +++++-
 doc/emacs/windows.texi | 22 +++++++++++++++++
 etc/NEWS               | 16 ++++++++++++
 lisp/bindings.el       | 34 ++++++++++++++++++++++++--
 lisp/window.el         | 55 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 132 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/screen.texi b/doc/emacs/screen.texi
index 5e9e89e6b11..d4e92c035b8 100644
--- a/doc/emacs/screen.texi
+++ b/doc/emacs/screen.texi
@@ -173,7 +173,7 @@ Mode Line
   The text displayed in the mode line has the following format:
 
 @example
- @var{cs}:@var{ch}-@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
+ @var{cs}:@var{ch}-@var{D}@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
 @end example
 
 @noindent
@@ -231,6 +231,12 @@ Mode Line
 However, if @code{default-directory} (@pxref{File Names}) for the
 current buffer is on a remote machine, @samp{@@} is displayed instead.
 
+  @var{D} appears if the window is dedicated to its current buffer.
+It appears as @samp{D} for strong dedication and @samp{d} for other
+forms of dedication.  If the window is not dedicated, @var{d} does not
+appear.  @xref{Dedicated Windows,, elisp, The Emacs Lisp Reference
+Manual}.
+
   @var{fr} gives the selected frame name (@pxref{Frames}).  It appears
 only on text terminals.  The initial frame's name is @samp{F1}.
 
diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
index e4abdef76be..b1c36aec426 100644
--- a/doc/emacs/windows.texi
+++ b/doc/emacs/windows.texi
@@ -411,6 +411,28 @@ Displaying Buffers
 window on some other frame to display the desired buffer.  Several of
 these commands are bound in the @kbd{C-x 5} prefix key.
 
+@cindex dedicated window
+  Sometimes, a window is ``dedicated'' to its current buffer
+@xref{Dedicated Windows,, elisp, The Emacs Lisp Reference Manual}.
+@code{display-buffer} will avoid reusing dedicated windows most of the
+time.  This is indicated by a ``d'' in the mode line (@pxref{Mode
+Line}).  A window can also be strongly dedicated, which prevents any
+changes to the buffer displayed in the window this is indicated by a
+``D'' in the mode line.
+
+Usually, dedicated windows are used to display specialized buffers,
+but dedication can sometimes be useful interactively.  For example,
+when viewing errors with @kbd{M-g M-n} @code{next-error}, newly
+displayed source code may replace a buffer you want to refer to.  If
+you dedicate a window to that buffer, the command (through
+@code{display-buffer}) will prefer to use a different window instead.
+
+@kindex C-x w d
+@findex toggle-window-dedicated
+  Toggle whether the selected window is dedicated to the current
+buffer.  With a prefix argument, make the window strongly dedicated
+instead.
+
 @menu
 * Window Choice::   How @code{display-buffer} works.
 * Temporary Displays::   Displaying non-editable buffers.
diff --git a/etc/NEWS b/etc/NEWS
index 3cfc36e10da..cd4c414a64c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -92,6 +92,22 @@ plus, minus, check-mark, start, etc.
 The 'tool-bar-position' frame parameter can be set to 'bottom' on all
 window systems other than Nextstep.
 
++++
+** 'd' in the mode line now indicates that the window is dedicated.
+Windows have always been able to be dedicated to a specific buffer;
+see 'window-dedicated-p'.  Now the mode line indicates the dedicated
+status of a window, with 'd' appearing in the mode line if a window is
+dedicated and 'D' if the window is strongly dedicated.  This indicator
+appears before the buffer name, and after the buffer modification and
+remote buffer indicators (usually "---" together).
+
++++
+** New command 'toggle-window-dedicated'.
+This makes it easy to interactively mark a specific window as
+dedicated, so it won't be reused by 'display-buffer'.  This can be
+useful for complicated window setups.  It is bound to 'C-x w d'
+globally.
+
 ** cl-print
 *** You can expand the "..." truncation everywhere.
 The code that allowed "..." to be expanded in the *Backtrace* should
diff --git a/lisp/bindings.el b/lisp/bindings.el
index f1a75b080be..1e05c1de43c 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -298,6 +298,35 @@ mode-line-frame-identification
 ;;;###autoload
 (put 'mode-line-frame-identification 'risky-local-variable t)
 
+(defvar mode-line-window-dedicated-keymap
+  (let ((map (make-sparse-keymap)))
+    (define-key map [mode-line mouse-1] #'toggle-window-dedicated)
+    (purecopy map)) "\
+Keymap for what is displayed by `mode-line-window-dedicated'.")
+
+(defun mode-line-window-control ()
+  "Compute mode line construct for window dedicated state.
+Value is used for `mode-line-window-dedicated', which see."
+  (cond
+   ((eq (window-dedicated-p) t)
+    `(:propertize
+      "D"
+      help-echo "Window strongly dedicated to its buffer\nmouse-1: Toggle"
+      local-map ,mode-line-window-dedicated-keymap
+      mouse-face 'mode-line-highlight))
+   ((window-dedicated-p)
+    `(:propertize
+      "d"
+      help-echo "Window dedicated to its buffer\nmouse-1: Toggle"
+      local-map ,mode-line-window-dedicated-keymap
+      mouse-face 'mode-line-highlight))
+   (t " ")))
+
+(defvar mode-line-window-dedicated '(:eval (mode-line-window-control))
+  "Mode line construct to describe the current window.")
+;;;###autoload
+(put 'mode-line-window-dedicated 'risky-local-variable t)
+
 (defvar-local mode-line-process nil
   "Mode line construct for displaying info on process status.
 Normally nil in most modes, since there is no process to display.")
@@ -673,8 +702,9 @@ mode-line-end-spaces
 	            'mode-line-mule-info
 	            'mode-line-client
 	            'mode-line-modified
-	            'mode-line-remote)
-              'display '(min-width (5.0)))
+		    'mode-line-remote
+		    'mode-line-window-dedicated)
+              'display '(min-width (6.0)))
 	     'mode-line-frame-identification
 	     'mode-line-buffer-identification
 	     "   "
diff --git a/lisp/window.el b/lisp/window.el
index d91bbabc010..f1677060310 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7463,6 +7463,60 @@ display-buffer-mark-dedicated
 The actual non-nil value of this variable will be copied to the
 `window-dedicated-p' flag.")
 
+(defcustom toggle-window-dedicated-flag 'interactive
+  "What dedicated flag should `toggle-window-dedicated' use by default.
+
+If `toggle-window-dedicated' does not receive a flag argument,
+the value of this variable is used and passed to
+`set-window-dedicated-p'.  Setting this to t will make
+`toggle-window-dedicated' use strong dedication by default.  Any
+other non-nil value will result in the same kind of non-strong
+dedication."
+  :type '(choice (const :tag "Strongly dedicated" t)
+                 (const :tag "Dedicated" interactive))
+  :version "30.0"
+  :group 'windows)
+
+(defun toggle-window-dedicated (&optional window flag interactive)
+  "Toggle whether WINDOW is dedicated to its current buffer.
+
+WINDOW must be a live window and defaults to the selected one.
+If FLAG is t (interactively, the prefix argument), make the window
+\"strongly\" dedicated to its buffer.  FLAG defaults to a non-nil,
+non-t value, and is passed to `set-window-dedicated-p', which see.
+If INTERACTIVE is non-nil, print a message describing the dedication
+status of WINDOW, after toggling it.  Interactively, this argument is
+always non-nil.
+
+When a window is dedicated to its buffer, `display-buffer' will avoid
+displaying another buffer in it, if possible.  When a window is
+strongly dedicated to its buffer, changing the buffer shown in the
+window will usually signal an error.
+
+You can control the default of FLAG with
+`toggle-window-dedicated-flag'.  Consequently, if you set that
+variable to t, strong dedication will be used by default.
+
+See the info node `(elisp)Dedicated Windows' for more details."
+  (interactive "i\nP\np")
+  (setq window (window-normalize-window window))
+  (setq flag (cond
+              ((consp flag) t)
+              ((null flag) toggle-window-dedicated-flag)
+              (t flag)))
+  (if (window-dedicated-p window)
+      (set-window-dedicated-p window nil)
+    (set-window-dedicated-p window flag))
+  (when interactive
+    (message "Window is %s dedicated to buffer %s"
+             (let ((status (window-dedicated-p window)))
+               (cond
+                ((null status) "no longer")
+                ((eq status t) "now strongly")
+                (t "now")))
+             (current-buffer))
+    (force-mode-line-update)))
+
 (defconst display-buffer--action-function-custom-type
   '(choice :tag "Function"
 	   (const :tag "--" ignore) ; default for insertion
@@ -10746,6 +10800,7 @@ window-prefix-map
   "2" #'split-root-window-below
   "3" #'split-root-window-right
   "s" #'window-toggle-side-windows
+  "d" #'toggle-window-dedicated
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-- 
2.41.0

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> Applied Eli's comments and added support for customizing which flag 
> toggle-window-dedicated sets by default.  New patch attached.
>

Seeing that all my suggestions (about the key binding, about the 
weak/strong distinction, and about the 
switch-to-buffer-in-dedicated-window configuration variable) have been 
ignored, I bow out of this thread.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Date: Mon, 21 Aug 2023 13:20:03 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, sbaugh@janestreet.com, philipk@posteo.net, 
>     rudalics@gmx.at, drew.adams@oracle.com, 64619@debbugs.gnu.org
> 
> Seeing that all my suggestions (about the key binding, about the 
> weak/strong distinction, and about the 
> switch-to-buffer-in-dedicated-window configuration variable) have been 
> ignored, I bow out of this thread.

They are not ignored.  We haven't yet installed anything.  We are
still discussing.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Cc: 64619@debbugs.gnu.org, philipk@posteo.net, sbaugh@janestreet.com,
>  sbaugh@catern.com, rudalics@gmx.at, drew.adams@oracle.com
> Date: Mon, 21 Aug 2023 17:02:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Mon, 21 Aug 2023 13:20:03 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: Eli Zaretskii <eliz@gnu.org>, sbaugh@janestreet.com, philipk@posteo.net, 
> >     rudalics@gmx.at, drew.adams@oracle.com, 64619@debbugs.gnu.org
> > 
> > Seeing that all my suggestions (about the key binding, about the 
> > weak/strong distinction, and about the 
> > switch-to-buffer-in-dedicated-window configuration variable) have been 
> > ignored, I bow out of this thread.
> 
> They are not ignored.  We haven't yet installed anything.  We are
> still discussing.

Can you tell why you dislike Spencer's last patch?  It allows an easy
customization to have the default that you wanted.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Mon, 21 Aug 2023 13:00:48 +0000 (UTC)
> Cc: sbaugh@janestreet.com, philipk@posteo.net, 64619@debbugs.gnu.org,
> 	drew.adams@oracle.com, rudalics@gmx.at
> 
> >> @@ -675,6 +696,7 @@ mode-line-end-spaces
> >>  	            'mode-line-modified
> >>  	            'mode-line-remote)
> >>                'display '(min-width (5.0)))
> >> +             'mode-line-window-dedicated
> >>  	     'mode-line-frame-identification
> >>  	     'mode-line-buffer-identification
> >>  	     "   "
> >
> > Why not add this to the group with the min-width property (and enlarge
> > that to 6.0)?  That way, we prevent annoying horizontal movement of
> > the rest of the mode-line display when toggling the state.
> 
> Hm, I tried doing that, but maybe I don't understand min-width, because
> there's still horizontal movement of the mode-line when I toggle it on
> and off.  I tried various combinations of strings, but they all had this
> behavior, maybe I'm doing something obviously wrong?

Look at how modeline-client was fixed recently, it had the same
problem.

> Also, if we make it fixed-size in this way, should we display "-"
> instead of nothing when the window is not dedicated? Or just an empty
> space?

Empty space is fine, and min-width will do that.

> - @var{cs}:@var{ch}-@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
> + @var{cs}:@var{ch}-@var{D}@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
>  @end example
>  
>  @noindent
> @@ -231,6 +231,12 @@ Mode Line
>  However, if @code{default-directory} (@pxref{File Names}) for the
>  current buffer is on a remote machine, @samp{@@} is displayed instead.
>  
> +  @var{D} appears if the window is dedicated to its current buffer.

This should be @var{d}, lower-case, as all the arguments of @var are.
makeinfo will either up-case it (for Info) or produce a slanted
typeface (for other output formats).

> +@cindex dedicated window
> +  Sometimes, a window is ``dedicated'' to its current buffer
                                                               ^
A period is missing there.

> +@code{display-buffer} will avoid reusing dedicated windows most of the
> +time.  This is indicated by a ``d'' in the mode line (@pxref{Mode
> +Line}).  A window can also be strongly dedicated, which prevents any
> +changes to the buffer displayed in the window this is indicated by a
> +``D'' in the mode line.

Why use ``d'' and ``D'' and not @samp?

> +You can control the default of FLAG with
> +`toggle-window-dedicated-flag'.  Consequently, if you set that
> +variable to t, strong dedication will be used by default.

The last sentence should say at the end "...and \\[universal-argument]
will make the window weakly dedicated."

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Mon, 21 Aug 2023 13:00:48 +0000 (UTC)
>> Cc: sbaugh@janestreet.com, philipk@posteo.net, 64619@debbugs.gnu.org,
>> 	drew.adams@oracle.com, rudalics@gmx.at
>> 
>> >> @@ -675,6 +696,7 @@ mode-line-end-spaces
>> >>  	            'mode-line-modified
>> >>  	            'mode-line-remote)
>> >>                'display '(min-width (5.0)))
>> >> +             'mode-line-window-dedicated
>> >>  	     'mode-line-frame-identification
>> >>  	     'mode-line-buffer-identification
>> >>  	     "   "
>> >
>> > Why not add this to the group with the min-width property (and enlarge
>> > that to 6.0)?  That way, we prevent annoying horizontal movement of
>> > the rest of the mode-line display when toggling the state.
>> 
>> Hm, I tried doing that, but maybe I don't understand min-width, because
>> there's still horizontal movement of the mode-line when I toggle it on
>> and off.  I tried various combinations of strings, but they all had this
>> behavior, maybe I'm doing something obviously wrong?
>
> Look at how modeline-client was fixed recently, it had the same
> problem.
>
>> Also, if we make it fixed-size in this way, should we display "-"
>> instead of nothing when the window is not dedicated? Or just an empty
>> space?
>
> Empty space is fine, and min-width will do that.
>
>> - @var{cs}:@var{ch}-@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
>> + @var{cs}:@var{ch}-@var{D}@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
>>  @end example
>>  
>>  @noindent
>> @@ -231,6 +231,12 @@ Mode Line
>>  However, if @code{default-directory} (@pxref{File Names}) for the
>>  current buffer is on a remote machine, @samp{@@} is displayed instead.
>>  
>> +  @var{D} appears if the window is dedicated to its current buffer.
>
> This should be @var{d}, lower-case, as all the arguments of @var are.
> makeinfo will either up-case it (for Info) or produce a slanted
> typeface (for other output formats).
>
>> +@cindex dedicated window
>> +  Sometimes, a window is ``dedicated'' to its current buffer
>                                                                ^
> A period is missing there.
>
>> +@code{display-buffer} will avoid reusing dedicated windows most of the
>> +time.  This is indicated by a ``d'' in the mode line (@pxref{Mode
>> +Line}).  A window can also be strongly dedicated, which prevents any
>> +changes to the buffer displayed in the window this is indicated by a
>> +``D'' in the mode line.
>
> Why use ``d'' and ``D'' and not @samp?
>
>> +You can control the default of FLAG with
>> +`toggle-window-dedicated-flag'.  Consequently, if you set that
>> +variable to t, strong dedication will be used by default.
>
> The last sentence should say at the end "...and \\[universal-argument]
> will make the window weakly dedicated."

All fixed, here's my revised patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-toggle-window-dedicated-command-and-mode-line-wi.patch --]
[-- Type: text/x-patch, Size: 10494 bytes --]

From d17c90d084a29430b2c131e34ff76d4e9762b8dc Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Sat, 19 Aug 2023 16:01:54 -0400
Subject: [PATCH] Add toggle-window-dedicated command and
 mode-line-window-dedicated

It's sometimes useful to interactively make certain windows dedicated.
This allows a level of interactive control over which window
display-buffer uses.

Additionally, when a window is dedicated (even without this new
command) it can affect display-buffer behavior in ways which may be
unexpected for users.  Let's display the window dedicated status in
the mode-line to help indicate what's going on.

* doc/emacs/windows.texi (Displaying Buffers): Add information about
dedicated windows and toggle-window-dedicated.
* doc/emacs/screen.texi (Mode Line): Add information about the window
dedicated indicator.
* etc/NEWS: Announce mode-line-window-dedicated and
toggle-window-dedicated.
* lisp/window.el (toggle-window-dedicated): Add.  (bug#64619)
(window-prefix-map): Add C-x w d binding.
* lisp/bindings.el (mode-line-window-control): Add.
(mode-line-window-dedicated): Add.
(standard-mode-line-format): Insert mode-line-window-dedicated.
---
 doc/emacs/screen.texi  |  8 +++++-
 doc/emacs/windows.texi | 22 ++++++++++++++++
 etc/NEWS               | 21 +++++++++++++++
 lisp/bindings.el       | 34 ++++++++++++++++++++++--
 lisp/window.el         | 59 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 141 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/screen.texi b/doc/emacs/screen.texi
index 5e9e89e6b11..3b910587260 100644
--- a/doc/emacs/screen.texi
+++ b/doc/emacs/screen.texi
@@ -173,7 +173,7 @@ Mode Line
   The text displayed in the mode line has the following format:
 
 @example
- @var{cs}:@var{ch}-@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
+ @var{cs}:@var{ch}-@var{d}@var{fr}  @var{buf}      @var{pos} @var{line}   (@var{major} @var{minor})
 @end example
 
 @noindent
@@ -231,6 +231,12 @@ Mode Line
 However, if @code{default-directory} (@pxref{File Names}) for the
 current buffer is on a remote machine, @samp{@@} is displayed instead.
 
+  @var{d} appears if the window is dedicated to its current buffer.
+It appears as @samp{D} for strong dedication and @samp{d} for other
+forms of dedication.  If the window is not dedicated, @var{d} does not
+appear.  @xref{Dedicated Windows,, elisp, The Emacs Lisp Reference
+Manual}.
+
   @var{fr} gives the selected frame name (@pxref{Frames}).  It appears
 only on text terminals.  The initial frame's name is @samp{F1}.
 
diff --git a/doc/emacs/windows.texi b/doc/emacs/windows.texi
index 665fd80e53b..ca5e424d939 100644
--- a/doc/emacs/windows.texi
+++ b/doc/emacs/windows.texi
@@ -411,6 +411,28 @@ Displaying Buffers
 window on some other frame to display the desired buffer.  Several of
 these commands are bound in the @kbd{C-x 5} prefix key.
 
+@cindex dedicated window
+  Sometimes, a window is ``dedicated'' to its current buffer.
+@xref{Dedicated Windows,, elisp, The Emacs Lisp Reference Manual}.
+@code{display-buffer} will avoid reusing dedicated windows most of the
+time.  This is indicated by a @samp{d} in the mode line (@pxref{Mode
+Line}).  A window can also be strongly dedicated, which prevents any
+changes to the buffer displayed in the window.  This is indicated by a
+@samp{D} in the mode line.
+
+Usually, dedicated windows are used to display specialized buffers,
+but dedication can sometimes be useful interactively.  For example,
+when viewing errors with @kbd{M-g M-n} @code{next-error}, newly
+displayed source code may replace a buffer you want to refer to.  If
+you dedicate a window to that buffer, the command (through
+@code{display-buffer}) will prefer to use a different window instead.
+
+@kindex C-x w d
+@findex toggle-window-dedicated
+  Toggle whether the selected window is dedicated to the current
+buffer.  With a prefix argument, make the window strongly dedicated
+instead.
+
 @menu
 * Window Choice::   How @code{display-buffer} works.
 * Temporary Displays::   Displaying non-editable buffers.
diff --git a/etc/NEWS b/etc/NEWS
index cfcb8104cca..647562143de 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -135,6 +135,27 @@ window systems other than Nextstep.
 When this minor mode is enabled, buttons representing modifier keys
 are displayed along the tool bar.
 
++++
+** 'd' in the mode line now indicates that the window is dedicated.
+Windows have always been able to be dedicated to a specific buffer;
+see 'window-dedicated-p'.  Now the mode line indicates the dedicated
+status of a window, with 'd' appearing in the mode line if a window is
+dedicated and 'D' if the window is strongly dedicated.  This indicator
+appears before the buffer name, and after the buffer modification and
+remote buffer indicators (usually "---" together).
+
++++
+** New command 'toggle-window-dedicated'.
+This makes it easy to interactively mark a specific window as
+dedicated, so it won't be reused by 'display-buffer'.  This can be
+useful for complicated window setups.  It is bound to 'C-x w d'
+globally.
+
+** cl-print
+*** You can expand the "..." truncation everywhere.
+The code that allowed "..." to be expanded in the *Backtrace* should
+now work anywhere the data is generated by `cl-print`.
+
 ---
 ** New user option 'uniquify-dirname-transform'.
 This can be used to customize how buffer names are uniquified, by
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 70e4087e131..418ee265e69 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -298,6 +298,35 @@ mode-line-frame-identification
 ;;;###autoload
 (put 'mode-line-frame-identification 'risky-local-variable t)
 
+(defvar mode-line-window-dedicated-keymap
+  (let ((map (make-sparse-keymap)))
+    (define-key map [mode-line mouse-1] #'toggle-window-dedicated)
+    (purecopy map)) "\
+Keymap for what is displayed by `mode-line-window-dedicated'.")
+
+(defun mode-line-window-control ()
+  "Compute mode line construct for window dedicated state.
+Value is used for `mode-line-window-dedicated', which see."
+  (cond
+   ((eq (window-dedicated-p) t)
+    (propertize
+     "D"
+     'help-echo "Window strongly dedicated to its buffer\nmouse-1: Toggle"
+     'local-map mode-line-window-dedicated-keymap
+     'mouse-face 'mode-line-highlight))
+   ((window-dedicated-p)
+    (propertize
+     "d"
+     'help-echo "Window dedicated to its buffer\nmouse-1: Toggle"
+     'local-map mode-line-window-dedicated-keymap
+     'mouse-face 'mode-line-highlight))
+   (t "")))
+
+(defvar mode-line-window-dedicated '(:eval (mode-line-window-control))
+  "Mode line construct to describe the current window.")
+;;;###autoload
+(put 'mode-line-window-dedicated 'risky-local-variable t)
+
 (defvar-local mode-line-process nil
   "Mode line construct for displaying info on process status.
 Normally nil in most modes, since there is no process to display.")
@@ -676,8 +705,9 @@ mode-line-end-spaces
 	            'mode-line-mule-info
 	            'mode-line-client
 	            'mode-line-modified
-	            'mode-line-remote)
-              'display '(min-width (5.0)))
+		    'mode-line-remote
+		    'mode-line-window-dedicated)
+              'display '(min-width (6.0)))
 	     'mode-line-frame-identification
 	     'mode-line-buffer-identification
 	     "   "
diff --git a/lisp/window.el b/lisp/window.el
index 2f9b46ebb0a..7c2ead7e5fe 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7468,6 +7468,64 @@ display-buffer-mark-dedicated
 The actual non-nil value of this variable will be copied to the
 `window-dedicated-p' flag.")
 
+(defcustom toggle-window-dedicated-flag 'interactive
+  "What dedicated flag should `toggle-window-dedicated' use by default.
+
+If `toggle-window-dedicated' does not receive a flag argument,
+the value of this variable is used and passed to
+`set-window-dedicated-p'.  Setting this to t will make
+`toggle-window-dedicated' use strong dedication by default.  Any
+other non-nil value will result in the same kind of non-strong
+dedication."
+  :type '(choice (const :tag "Strongly dedicated" t)
+                 (const :tag "Dedicated" interactive))
+  :version "30.0"
+  :group 'windows)
+
+(defun toggle-window-dedicated (&optional window flag interactive)
+  "Toggle whether WINDOW is dedicated to its current buffer.
+
+WINDOW must be a live window and defaults to the selected one.
+If FLAG is t (interactively, the prefix argument), make the window
+\"strongly\" dedicated to its buffer.  FLAG defaults to a non-nil,
+non-t value, and is passed to `set-window-dedicated-p', which see.
+If INTERACTIVE is non-nil, print a message describing the dedication
+status of WINDOW, after toggling it.  Interactively, this argument is
+always non-nil.
+
+When a window is dedicated to its buffer, `display-buffer' will avoid
+displaying another buffer in it, if possible.  When a window is
+strongly dedicated to its buffer, changing the buffer shown in the
+window will usually signal an error.
+
+You can control the default of FLAG with
+`toggle-window-dedicated-flag'.  Consequently, if you set that
+variable to t, strong dedication will be used by default and
+\\[universal-argument] will make the window weakly dedicated.
+
+See the info node `(elisp)Dedicated Windows' for more details."
+  (interactive "i\nP\np")
+  (setq window (window-normalize-window window))
+  (setq flag (cond
+              ((consp flag)
+               (if (eq toggle-window-dedicated-flag t)
+                   'interactive
+                 t))
+              ((null flag) toggle-window-dedicated-flag)
+              (t flag)))
+  (if (window-dedicated-p window)
+      (set-window-dedicated-p window nil)
+    (set-window-dedicated-p window flag))
+  (when interactive
+    (message "Window is %s dedicated to buffer %s"
+             (let ((status (window-dedicated-p window)))
+               (cond
+                ((null status) "no longer")
+                ((eq status t) "now strongly")
+                (t "now")))
+             (current-buffer))
+    (force-mode-line-update)))
+
 (defconst display-buffer--action-function-custom-type
   '(choice :tag "Function"
 	   (const :tag "--" ignore) ; default for insertion
@@ -10750,6 +10808,7 @@ window-prefix-map
   "2" #'split-root-window-below
   "3" #'split-root-window-right
   "s" #'window-toggle-side-windows
+  "d" #'toggle-window-dedicated
   "^ f" #'tear-off-window
   "^ t" #'tab-window-detach
   "-" #'fit-window-to-buffer
-- 
2.41.0

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Fri, 13 Oct 2023 01:33:11 +0000 (UTC)
> Cc: sbaugh@janestreet.com, philipk@posteo.net, rudalics@gmx.at,
> 	drew.adams@oracle.com, 64619@debbugs.gnu.org
> 
> All fixed, here's my revised patch.

Thanks, installed on the master branch, and closing the bug.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>> OK, this patch adds support for making the buffer strongly dedicated 
>> with a prefix argument, and also adds an indicator to the mode line of 
>> whether the current window is dedicated (which seems useful even if we 
>> don't apply the toggle part of this patch).
>
> Any thoughts on this patch?
>

Two thoughs:

1. I would simplify the body of toggle-window-dedicated, using

(set-window-dedicated-p window (not (window-dedicated-p)))

This makes the window "strongly" dedicated, which is more in line with 
what "Window will now display only its current buffer" promises (e.g. C-x 
b will refuse to switch to another buffer).

2. I would not bind it to the "d" key but to the "!" key: ISTM that 
toggling window dedication is not such a common action that it needs a 
letter key binding.

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Gregory Heytings <gregory@heytings.org> writes:

>>> OK, this patch adds support for making the buffer strongly
>>> dedicated with a prefix argument, and also adds an indicator to the
>>> mode line of whether the current window is dedicated (which seems
>>> useful even if we don't apply the toggle part of this patch).
>>
>> Any thoughts on this patch?
>>
>
> Two thoughs:
>
> 1. I would simplify the body of toggle-window-dedicated, using
>
> (set-window-dedicated-p window (not (window-dedicated-p)))
>
> This makes the window "strongly" dedicated, which is more in line with
> what "Window will now display only its current buffer" promises
> (e.g. C-x b will refuse to switch to another buffer).

Ah, see earlier discussion.  We at least want to be able to choose
between strong and non-strong dedication.  And having used this command
I think non-strong dedication is a much better default, since it allows
users to explicitly run C-x b to change buffers without having to switch
off dedication.

> 2. I would not bind it to the "d" key but to the "!" key: ISTM that
> toggling window dedication is not such a common action that it needs a
> letter key binding.

It's not common at the moment, but I expect some users will use this
command quite frequently.  Also the C-x w prefix is pretty empty at the
moment, so it's not as if it's competing with anything.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>> This makes the window "strongly" dedicated, which is more in line with 
>> what "Window will now display only its current buffer" promises (e.g. 
>> C-x b will refuse to switch to another buffer).
>
> Ah, see earlier discussion.
>

Sorry, I missed that in the earlier discussion.

>
> We at least want to be able to choose between strong and non-strong 
> dedication.  And having used this command I think non-strong dedication 
> is a much better default, since it allows users to explicitly run C-x b 
> to change buffers without having to switch off dedication.
>

I agree with Drew here: strong dedication would be a better default.  The 
fact that the window was weakly dedicated and that I could switch to 
another buffer without any warning or confirmation surprised me when I 
tried your patch, hence my reaction.  Dedicating a window to a buffer is 
somewhat like making a buffer read-only, and I guess "weak read-onlyness" 
would be surprising to most users.

>> 2. I would not bind it to the "d" key but to the "!" key: ISTM that 
>> toggling window dedication is not such a common action that it needs a 
>> letter key binding.
>
> It's not common at the moment, but I expect some users will use this 
> command quite frequently.  Also the C-x w prefix is pretty empty at the 
> moment, so it's not as if it's competing with anything.
>

It's pretty empty, but IMO that's not a reason to use its "best" bindings 
for something like this.  "d" should IMO be used for "delete" (yes, I know 
it's already available with C-x 0).  See 
https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00326.html.

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Gregory Heytings <gregory@heytings.org> writes:
> I agree with Drew here: strong dedication would be a better default.
> The fact that the window was weakly dedicated and that I could switch
> to another buffer without any warning or confirmation surprised me
> when I tried your patch, hence my reaction.  Dedicating a window to a
> buffer is somewhat like making a buffer read-only, and I guess "weak
> read-onlyness" would be surprising to most users.

Maybe it's surprising to Emacs developers, but I think strong dedication
would be more surprising to users.

In fact, I initially used strong dedication in my patch.  But I found it
annoying that I had to turn off strong dedication explicitly if I wanted
to switch to another buffer.  That's what made me realize that weak
dedication was better.

Strong dedication would make sense if C-x b used display-buffer.  Then
it would be very helpful: C-x b in a strongly dedicated window would
automatically use another window, which would be nice for muscle memory
since you could just use C-x b regardless of what window you're in.  But
C-x b doesn't use display buffer, and instead just errors when the
current window is strongly dedicated, which I think is fairly useless
behavior; the user reaction is almost always going to be annoyance
followed by C-x w d and C-x b again. So I think weak dedication is
better.  (Or making C-x b use display-buffer?)

>>> 2. I would not bind it to the "d" key but to the "!" key: ISTM that
>>> toggling window dedication is not such a common action that it
>>> needs a letter key binding.
>>
>> It's not common at the moment, but I expect some users will use this
>> command quite frequently.  Also the C-x w prefix is pretty empty at
>> the moment, so it's not as if it's competing with anything.
>>
>
> It's pretty empty, but IMO that's not a reason to use its "best"
> bindings for something like this.  "d" should IMO be used for "delete"
> (yes, I know it's already available with C-x 0).  See
> https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00326.html.

Eh, I agree with others in that thread, I don't think C-x w d should run
delete-buffer. :)

But this does make me think that maybe toggle-window-dedicated should
not have a default binding at first.  We can see if people use it and
only then give it a binding.  I'm fine with that.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> In fact, I initially used strong dedication in my patch.  But I found it 
> annoying that I had to turn off strong dedication explicitly if I wanted 
> to switch to another buffer.  That's what made me realize that weak 
> dedication was better.
>

It's not annoying, it's what dedication is for.  It's not more annoying 
than using C-x C-q in a buffer, and later typing something in that buffer 
and realizing (with a similar error message) that it doesn't work: you get 
what you asked.

>
> But C-x b doesn't use display buffer, and instead just errors when the 
> current window is strongly dedicated, which I think is fairly useless 
> behavior; the user reaction is almost always going to be annoyance 
> followed by C-x w d and C-x b again. So I think weak dedication is 
> better.
>

If you think that's annoying, then I'd suggest setting the 
switch-to-buffer-in-dedicated-window configuration option.  It's there for 
a reason, and you can select between no less than four behaviors: one of 
them is likely the one you want.

>
> Eh, I agree with others in that thread, I don't think C-x w d should run 
> delete-buffer. :)
>

I don't know which "others" you have in mind, I do recall that some 
disagreed (is there a single topic on emacs-devel on which no one 
disagrees?), but IIRC at least Lars said that it would be nice to have a 
full repertoire of commands to manage windows under C-x w.

>
> But this does make me think that maybe toggle-window-dedicated should 
> not have a default binding at first.  We can see if people use it and 
> only then give it a binding.  I'm fine with that.
>

I'm fine with that, too.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Date: Sat, 19 Aug 2023 22:36:45 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Spencer Baugh <sbaugh@janestreet.com>, 
>     Philip Kaludercic <philipk@posteo.net>, 64619@debbugs.gnu.org, 
>     martin rudalics <rudalics@gmx.at>, Eli Zaretskii <eliz@gnu.org>, 
>     Drew Adams <drew.adams@oracle.com>
> 
> 
> >
> > In fact, I initially used strong dedication in my patch.  But I found it 
> > annoying that I had to turn off strong dedication explicitly if I wanted 
> > to switch to another buffer.  That's what made me realize that weak 
> > dedication was better.
> >
> 
> It's not annoying, it's what dedication is for.  It's not more annoying 
> than using C-x C-q in a buffer, and later typing something in that buffer 
> and realizing (with a similar error message) that it doesn't work: you get 
> what you asked.
> 
> >
> > But C-x b doesn't use display buffer, and instead just errors when the 
> > current window is strongly dedicated, which I think is fairly useless 
> > behavior; the user reaction is almost always going to be annoyance 
> > followed by C-x w d and C-x b again. So I think weak dedication is 
> > better.
> >
> 
> If you think that's annoying, then I'd suggest setting the 
> switch-to-buffer-in-dedicated-window configuration option.  It's there for 
> a reason, and you can select between no less than four behaviors: one of 
> them is likely the one you want.

I think the reason that people disagree about the details is because
they have different use cases for this feature in mind.

To reconcile these two opinions, we could introduce a user option
which would invert the default: make strongly-dedicated the default
and weekly-dedicated the optional kind requiring C-u.

Alternatively, we could use switch-to-buffer-in-dedicated-window as
that user option: if the user sets it non-nil, we could take that as
an indication that they prefer the strongly-dedicated default.

WDYT?

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> Alternatively, we could use switch-to-buffer-in-dedicated-window as that 
> user option: if the user sets it non-nil, we could take that as an 
> indication that they prefer the strongly-dedicated default.
>

IMO it would be much cleaner to just strongly dedicate the window in 
toggle-window-dedicated, and to add a note in its docstring pointing to 
switch-to-buffer-in-dedicated-window and explaining that that option 
should be used to decide what happens with C-x b.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Date: Sun, 20 Aug 2023 08:02:25 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 64619@debbugs.gnu.org, philipk@posteo.net, sbaugh@janestreet.com, 
>     sbaugh@catern.com, rudalics@gmx.at, drew.adams@oracle.com
> 
> > Alternatively, we could use switch-to-buffer-in-dedicated-window as that 
> > user option: if the user sets it non-nil, we could take that as an 
> > indication that they prefer the strongly-dedicated default.
> 
> IMO it would be much cleaner to just strongly dedicate the window in 
> toggle-window-dedicated, and to add a note in its docstring pointing to 
> switch-to-buffer-in-dedicated-window and explaining that that option 
> should be used to decide what happens with C-x b.

So you are saying that opinions of people who disagree with you should
be simply disregarded?

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>>> Alternatively, we could use switch-to-buffer-in-dedicated-window as 
>>> that user option: if the user sets it non-nil, we could take that as 
>>> an indication that they prefer the strongly-dedicated default.
>>
>> IMO it would be much cleaner to just strongly dedicate the window in 
>> toggle-window-dedicated, and to add a note in its docstring pointing to 
>> switch-to-buffer-in-dedicated-window and explaining that that option 
>> should be used to decide what happens with C-x b.
>
> So you are saying that opinions of people who disagree with you should 
> be simply disregarded?
>

Hmmm... no.  Where do you see that?  I'm simply saying that a user option 
to control how C-x b behaves with a (strongly) dedicated window already 
exists, which means that the behavior that Spencer found annoying can 
already be tweaked, and that it is not necessary to add yet another user 
option to control that behavior.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Date: Sun, 20 Aug 2023 08:41:50 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 64619@debbugs.gnu.org, philipk@posteo.net, sbaugh@janestreet.com, 
>     sbaugh@catern.com, rudalics@gmx.at, drew.adams@oracle.com
> 
> >> IMO it would be much cleaner to just strongly dedicate the window in 
> >> toggle-window-dedicated, and to add a note in its docstring pointing to 
> >> switch-to-buffer-in-dedicated-window and explaining that that option 
> >> should be used to decide what happens with C-x b.
> >
> > So you are saying that opinions of people who disagree with you should 
> > be simply disregarded?
> 
> Hmmm... no.  Where do you see that?  I'm simply saying that a user option 
> to control how C-x b behaves with a (strongly) dedicated window already 
> exists, which means that the behavior that Spencer found annoying can 
> already be tweaked, and that it is not necessary to add yet another user 
> option to control that behavior.

A user who didn't customize switch-to-buffer-in-dedicated-window does
not necessarily want his/her dedicated windows to be strongly
dedicated by default.  Which is why one of the alternatives I
suggested is to use the value of that variable as the indication which
kind of dedication to use by default.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> A user who didn't customize switch-to-buffer-in-dedicated-window does 
> not necessarily want his/her dedicated windows to be strongly dedicated 
> by default.  Which is why one of the alternatives I suggested is to use 
> the value of that variable as the indication which kind of dedication to 
> use by default.
>

That wouldn't really work, alas.  The mapping would be:

switch-to-buffer-in-dedicated-window t => weakly dedicated

switch-to-buffer-in-dedicated-window non-t => strongly dedicated

Weakly dedicating a window when switch-to-buffer-in-dedicated-window is t 
is not really useful.  And the default value of 
switch-to-buffer-in-dedicated-window is nil, so the default would be 
strongly dedicated anyway.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> Date: Sun, 20 Aug 2023 09:56:06 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 64619@debbugs.gnu.org, philipk@posteo.net, sbaugh@janestreet.com, 
>     sbaugh@catern.com, rudalics@gmx.at, drew.adams@oracle.com
> 
> > A user who didn't customize switch-to-buffer-in-dedicated-window does 
> > not necessarily want his/her dedicated windows to be strongly dedicated 
> > by default.  Which is why one of the alternatives I suggested is to use 
> > the value of that variable as the indication which kind of dedication to 
> > use by default.
> 
> That wouldn't really work, alas.  The mapping would be:
> 
> switch-to-buffer-in-dedicated-window t => weakly dedicated
> 
> switch-to-buffer-in-dedicated-window non-t => strongly dedicated

I meant the opposite mapping, actually.

> Weakly dedicating a window when switch-to-buffer-in-dedicated-window is t 
> is not really useful.  And the default value of 
> switch-to-buffer-in-dedicated-window is nil, so the default would be 
> strongly dedicated anyway.

There's an inherent problem with using
switch-to-buffer-in-dedicated-window for this purpose anyway: it
doesn't necessarily allow switch-to-buffer to change the buffer in
such a window, it might ask the user whether to switch, and the window
is no longer dedicated if the switch takes place.

So I don't think this variable can serve the user preference for
whether the window should be strongly or weekly dedicated by default.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> So I don't think this variable can serve the user preference for whether 
> the window should be strongly or weekly dedicated by default.
>

Agreed.

Let's now see whether Spencer agrees that using that variable to tweak the 
behavior of C-x b is enough to avoid the annoyance he experienced.

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Gregory Heytings <gregory@heytings.org> writes:
>> So I don't think this variable can serve the user preference for
>> whether the window should be strongly or weekly dedicated by
>> default.
>>
>
> Agreed.
>
> Let's now see whether Spencer agrees that using that variable to tweak
> the behavior of C-x b is enough to avoid the annoyance he experienced.

I didn't know about switch-to-buffer-in-dedicated-window.  It does
resolve the basic annoyance I described, of C-x b not working.

But, it affects all windows, not just ones that have been interactively
dedicated by the user.  I personally have just set
switch-to-buffer-in-dedicated-window to `pop', so that C-x b works when
I happen to be in a window which was made strongly dedicated by a Lisp
program.  But for windows which I interactively choose to dedicate with
toggle-window-dedicated, I think I'd prefer the `t' behavior.  Which is
effectively what we have now by weakly dedicating the window.

(Further in the vein of "customizing different window dedications
differently", maybe toggle-window-dedicated should even have its own
unique dedication symbol by default, `interactively' or something, so a
user can customize the behavior of that without affecting other windows.
That would mean weak dedication by default, of course.)

I would be fine with a variable controlling what toggle-window-dedicated
does.  In the "unique dedication symbol for toggle-window-dedicated"
case that variable could just hold that symbol and if people want strong
dedication they can set it to `t'.

---

Completely separate suggestion and possible resolution: Maybe we can
have two commands, one which does weak dedication and the other strong
dedication?  And eventually, when we add keybindings, we could have weak
bound to C-x w d and strong to C-x w D?

I suggest this because the indicator I added to the mode line shows 'd'
for weak dedication and 'D' for strong dedication.  And while testing, I
just unthinkingly tried to do strong dedication (instead of weak) by
hitting C-x w D (instead of C-x w d).  That is, I just assumed that the
keybindings would match the mode line indicator.  Which actually seems
like it would be a very good idea so maybe we should do that.

And if we did that, it would resolve the issue of defaults since both
options would be easily accessible.  And it's not too wasteful of
keybinding space since we rarely bind both lowercase and uppercase keys
anyway, so we probably already wouldn't use C-x w D for anything else.

We wouldn't add the bindings at first though, since we should not just
assume that people will start using this command.  So for now this would
just mean adding a second toggle-window-dedication-strong command, which
people who want strong dedication can use.

Gregory mentioned not liking C-x w d, so we could also change the
indicator and the expected future keybinding to something other than d/D
- any suggestions?  Although personally I think d/D is good.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Sun, 20 Aug 2023 14:09:35 +0000 (UTC)
> Cc: Eli Zaretskii <eliz@gnu.org>, 64619@debbugs.gnu.org, philipk@posteo.net,
> 	sbaugh@janestreet.com, rudalics@gmx.at, drew.adams@oracle.com
> 
> Completely separate suggestion and possible resolution: Maybe we can
> have two commands, one which does weak dedication and the other strong
> dedication?

That'd be overkill, IMO.  The single command is already borderline
(since dedicated windows were not introduced as an interactive
feature, but rather as a means for Lisp programs to control
display-buffer's otherwise "wild West" type behavior).  Having two
commands is completely overboard.  Let's not take this ad absurdum.

(Of course, you can always have a special command in your local init
file, if you need them both.  Here we are talking about what the
majority of Emacs users will need.)

bug#64619: [PATCH] Add toggle-window-dedicated command

[Gregory Heytings]

>
> I didn't know about switch-to-buffer-in-dedicated-window.  It does 
> resolve the basic annoyance I described, of C-x b not working.
>

Great!

>
> But, it affects all windows, not just ones that have been interactively 
> dedicated by the user.
>

Indeed, that option is used for C-x b in all dedicated windows.

>
> I personally have just set switch-to-buffer-in-dedicated-window to 
> `pop', so that C-x b works when I happen to be in a window which was 
> made strongly dedicated by a Lisp program.  But for windows which I 
> interactively choose to dedicate with toggle-window-dedicated, I think 
> I'd prefer the `t' behavior.  Which is effectively what we have now by 
> weakly dedicating the window.
>

It is wise to go into such refinements for a new command that, as Eli 
says, is a bit borderline?  Right now window dedication is not even 
mentioned in the Emacs manual.  Perhaps a new value for 
switch-to-buffer-in-dedicated-window, which would prompt the user and 
offer them the choice to either display the buffer in the current window 
or in another window, would be enough (and more generally useful)?

bug#64619: [PATCH] Add toggle-window-dedicated command

[sbaugh]

Gregory Heytings <gregory@heytings.org> writes:
>>
>> I didn't know about switch-to-buffer-in-dedicated-window.  It does
>> resolve the basic annoyance I described, of C-x b not working.
>>
>
> Great!

To be clear, as I said, I still don't think the existence of
switch-to-buffer-in-dedicated-window means toggle-window-dedicated
should default to weak dedication :)

>> But, it affects all windows, not just ones that have been
>> interactively dedicated by the user.
>>
>
> Indeed, that option is used for C-x b in all dedicated windows.
>
>>
>> I personally have just set switch-to-buffer-in-dedicated-window to
>> `pop', so that C-x b works when I happen to be in a window which was
>> made strongly dedicated by a Lisp program.  But for windows which I
>> interactively choose to dedicate with toggle-window-dedicated, I
>> think I'd prefer the `t' behavior.  Which is effectively what we
>> have now by weakly dedicating the window.
>>
>
> It is wise to go into such refinements for a new command that, as Eli
> says, is a bit borderline?  Right now window dedication is not even
> mentioned in the Emacs manual.  Perhaps a new value for
> switch-to-buffer-in-dedicated-window, which would prompt the user and
> offer them the choice to either display the buffer in the current
> window or in another window, would be enough (and more generally
> useful)?

No "refinments" are necessary, this is exactly the behavior which is
achieved by just using weak dedication, like the command in my patch
currently does.

I'm happy to make it customizable, though.  I just believe the default
should be weak dedication.

bug#64619: [PATCH] Add toggle-window-dedicated command

[Augusto Stoffel]

On Sat, 19 Aug 2023 at 20:37, Gregory Heytings wrote:

> It's pretty empty, but IMO that's not a reason to use its "best"
> bindings for something like this.  "d" should IMO be used for "delete"
> (yes, I know it's already available with C-x 0).  See
> https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00326.html.

Another candidate for the "d" command would be this one (which you
called soft delete):

  https://yhetil.org/emacs-devel/84acc36e7edde6dee845@heytings.org/

(BTW, +1 for a "toggle dedicated window" command, I have something
similar and think it's useful.)