From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64619: [PATCH] Add toggle-window-dedicated command Date: Sun, 20 Aug 2023 08:57:26 +0300 Message-ID: <83il9axnll.fsf@gnu.org> References: <87h6ovgnpn.fsf@catern.com> <874jkvvwm2.fsf@posteo.net> <87jztr0zt7.fsf@catern.com> <87zg2nuho0.fsf@posteo.net> <877cpqreat.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, philipk@posteo.net, 64619@debbugs.gnu.org, drew.adams@oracle.com, rudalics@gmx.at To: sbaugh@catern.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 20 07:58:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qXbS4-0004wd-En for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Aug 2023 07:58:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXbRu-0004aI-LO; Sun, 20 Aug 2023 01:58:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXbRp-0004Yk-FU for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 01:58:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qXbRp-0007pI-6v for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 01:58:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qXbRq-0008JF-65 for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 01:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2023 05:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64619 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 64619-submit@debbugs.gnu.org id=B64619.169251104531894 (code B ref 64619); Sun, 20 Aug 2023 05:58:02 +0000 Original-Received: (at 64619) by debbugs.gnu.org; 20 Aug 2023 05:57:25 +0000 Original-Received: from localhost ([127.0.0.1]:52727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXbRE-0008IK-L1 for submit@debbugs.gnu.org; Sun, 20 Aug 2023 01:57:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXbRC-0008I3-K7 for 64619@debbugs.gnu.org; Sun, 20 Aug 2023 01:57:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXbR3-0007lm-UD; Sun, 20 Aug 2023 01:57:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=A/oQXpbzQKc38OGUSzHApJvBAuo4/CauqfL66LRvLOg=; b=k00ctsoXkGGR arOPqaOxE8gMsXc/fIrjC7wSPtXFW5KvIMbSSiyIXoecSu/Y1vGhrrssHmibC+izgdHlweKZB2iqP K662m1oyt3iNqw0w+aztbkEe2zpafEtvSg2CaTX3Iojst06C9uFYDzC7JSYyVweoo0eYV+GLK1eDl EXr6/4GR/C5411rIex4pYIZ9V5NJDVUS07AzOFcHzu5amdLTxRk8YGaEHP5is91VdTfUvrE3Wma7w g6P7oiqqNW/3wZcw0JZZtk+mzpu6k3roCI0Tj+9HxoMzngrpimGzwKIb8ES8Eho8tZhk/aIIYVoJm 6NSRkjbdUaS1q2oMQLLNog==; In-Reply-To: <877cpqreat.fsf@catern.com> (sbaugh@catern.com) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267941 Archived-At: > From: sbaugh@catern.com > Date: Sat, 19 Aug 2023 20:02:35 +0000 (UTC) > Cc: Spencer Baugh , Eli Zaretskii , > martin rudalics , Drew Adams , > 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.