From: Drew Adams <drew.adams@oracle.com>
To: "sbaugh@catern.com" <sbaugh@catern.com>
Cc: Spencer Baugh <sbaugh@janestreet.com>,
Philip Kaludercic <philipk@posteo.net>,
"64619@debbugs.gnu.org" <64619@debbugs.gnu.org>
Subject: bug#64619: [PATCH] Add toggle-window-dedicated command
Date: Sat, 15 Jul 2023 21:30:17 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488330210B84C253740CFD8F335A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87zg3yhwpe.fsf@catern.com>
> > 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. ;-))
next prev parent reply other threads:[~2023-07-15 21:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 15:38 bug#64619: [PATCH] Add toggle-window-dedicated command Spencer Baugh
2023-07-14 19:42 ` Philip Kaludercic
2023-07-14 21:17 ` Drew Adams
2023-07-14 23:58 ` sbaugh
2023-07-15 21:30 ` Drew Adams [this message]
2023-07-18 15:35 ` Spencer Baugh
2023-07-18 17:56 ` Philip Kaludercic
2023-07-15 5:44 ` Eli Zaretskii
2023-07-15 7:53 ` martin rudalics
2023-07-15 17:41 ` sbaugh
2023-07-15 18:16 ` martin rudalics
2023-07-18 15:34 ` Spencer Baugh
2023-08-19 13:34 ` sbaugh
2023-08-19 16:13 ` Philip Kaludercic
2023-08-19 16:20 ` sbaugh
2023-08-19 16:21 ` Philip Kaludercic
2023-08-19 20:02 ` sbaugh
2023-08-20 5:57 ` Eli Zaretskii
2023-08-21 13:00 ` sbaugh
2023-08-21 13:20 ` Gregory Heytings
2023-08-21 14:02 ` Eli Zaretskii
2023-08-21 19:22 ` Eli Zaretskii
2023-08-21 19:20 ` Eli Zaretskii
2023-10-13 1:33 ` sbaugh
2023-10-25 13:46 ` Eli Zaretskii
2023-08-19 16:43 ` Gregory Heytings
2023-08-19 20:06 ` sbaugh
2023-08-19 20:37 ` Gregory Heytings
2023-08-19 21:47 ` sbaugh
2023-08-19 22:36 ` Gregory Heytings
2023-08-20 6:13 ` Eli Zaretskii
2023-08-20 8:02 ` Gregory Heytings
2023-08-20 8:30 ` Eli Zaretskii
2023-08-20 8:41 ` Gregory Heytings
2023-08-20 8:54 ` Eli Zaretskii
2023-08-20 9:56 ` Gregory Heytings
2023-08-20 10:11 ` Eli Zaretskii
2023-08-20 10:25 ` Gregory Heytings
2023-08-20 14:09 ` sbaugh
2023-08-20 15:31 ` Eli Zaretskii
2023-08-20 21:56 ` Gregory Heytings
2023-08-21 11:23 ` sbaugh
2023-08-21 8:27 ` Augusto Stoffel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB5488330210B84C253740CFD8F335A@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=64619@debbugs.gnu.org \
--cc=philipk@posteo.net \
--cc=sbaugh@catern.com \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).