From: Eli Zaretskii <eliz@gnu.org>
To: sbaugh@catern.com
Cc: sbaugh@janestreet.com, philipk@posteo.net, 64619@debbugs.gnu.org,
drew.adams@oracle.com, rudalics@gmx.at
Subject: bug#64619: [PATCH] Add toggle-window-dedicated command
Date: Sun, 20 Aug 2023 08:57:26 +0300 [thread overview]
Message-ID: <83il9axnll.fsf@gnu.org> (raw)
In-Reply-To: <877cpqreat.fsf@catern.com> (sbaugh@catern.com)
> 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.
next prev parent reply other threads:[~2023-08-20 5:57 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 [this message]
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=83il9axnll.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=64619@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=philipk@posteo.net \
--cc=rudalics@gmx.at \
--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).