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

From: Drew Adams <[email-masked]>
Date: Fri, 14 Jul 2023 21:17:18 +0000

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?