unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: sbaugh@catern.com
To: Gregory Heytings <gregory@heytings.org>
Cc: 64619@debbugs.gnu.org, philipk@posteo.net, sbaugh@janestreet.com,
	rudalics@gmx.at, Eli Zaretskii <eliz@gnu.org>,
	drew.adams@oracle.com
Subject: bug#64619: [PATCH] Add toggle-window-dedicated command
Date: Sun, 20 Aug 2023 14:09:35 +0000 (UTC)	[thread overview]
Message-ID: <87fs4dpzz5.fsf@catern.com> (raw)
In-Reply-To: <22de08b62b4b6e98a722@heytings.org> (Gregory Heytings's message of "Sun, 20 Aug 2023 10:25:08 +0000")

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.





  reply	other threads:[~2023-08-20 14:09 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
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 [this message]
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=87fs4dpzz5.fsf@catern.com \
    --to=sbaugh@catern.com \
    --cc=64619@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=gregory@heytings.org \
    --cc=philipk@posteo.net \
    --cc=rudalics@gmx.at \
    --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).