From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 31858@debbugs.gnu.org
Subject: bug#31858: 27.0; doc of `window-toggle-side-windows'
Date: Sat, 16 Jun 2018 17:14:56 -0700 (PDT) [thread overview]
Message-ID: <1e768b88-46ea-4e55-9403-2ce27d1cc63c@default> (raw)
In-Reply-To: <87in6itj6c.fsf@gmail.com>
> > The doc should say that the function deletes all side windows
> > of FRAME, or it restores all such previously deleted side windows.
>
> Seems like it does say that?
Not in so many words. You have to read carefully to figure
out just what's being toggled here: the presence/validity of
(all) side windows.
If the function were called `delete/restore-side-windows'
then there would be no problem. The doc string would then
only need to make clear that this means _all_ side windows.
End of story. We can guess what deleting and restoring a
window means. But toggling a window?
When the name is "toggle" the doc should (explicitly) say
what it is that is toggled - what state/quality. A name
such as `toggle-foo-visibility' makes clear that it is the
_visibility_ of a foo or foo's that gets toggled.
What's toggled here? Surely it's not a "window" (unless
you want to explicitly define "toggling" a window to mean
what this function does).
Here, the name of the state that is toggled is (apparently)
the presence, or the existence, or (I guess) the "validity"
of side windows. The paragraph you mention describes the
deletion and restoring action, but it doesn't name the
state/quality that is _toggled_. That's all.
"toggle the _appearance_ of all side windows" sounds to
me like perhaps something about the appearance - _how_
it looks gets toggled.
In fact, IIUC it is the "validity" of the side windows
that gets toggled. Not really their existence or their
appearance or their presences (in Lisp), but their
"validity".
I think the doc says that "deletion" of a window object
does not mean that the object no longer exists: it can
be restored.
Sounds similar to, say, overlays. When we "delete" an
overlay we don't say that its "appearance" changes or is
"toggled". We do carefully point out, just as we do for
windows, that the overlay object continues to exist etc.
We should use whatever the appropriate terminology is, for
windows. I'm no expert on what term is best here. A quick
reading of the window doc gave me the impression that the
term is "validity" - deleted window objects exist but are
not "valid".
A “valid window” is one that is either live or internal.
A valid window can be “deleted”, i.e., removed from its
frame (*note Deleting Windows::); then it is no longer valid,
but the Lisp object representing it might be still referenced
from other Lisp objects. A deleted window may be made valid
again by restoring a saved window configuration (*note
Window Configurations::). -- node `Basic Windows'
(That also defines what "deleting" a window means, BTW.
If the doc string pointed to that manual node, it wouldn't
hurt.)
All I can say is that saying that the side "_windows are
toggled_" doesn't make sense. That's OK for a function
name, but not for an explanation.
Or if you really want to talk about "toggling a window" then
please add something like "toggling a window means...".
I guess that here it means just what I said: "the function
deletes all side windows ... or it restores all such
previously deleted side windows."
HTH.
next prev parent reply other threads:[~2018-06-17 0:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-16 12:35 bug#31858: 27.0; doc of `window-toggle-side-windows' Drew Adams
2018-06-16 16:28 ` Eli Zaretskii
2018-06-16 23:11 ` Drew Adams
2018-06-16 23:18 ` Noam Postavsky
2018-06-17 0:14 ` Drew Adams [this message]
2018-06-17 3:46 ` Eli Zaretskii
[not found] <<65951719-2046-44e9-8946-692a7a15d6d0@default>
[not found] ` <<837emyzofh.fsf@gnu.org>
[not found] ` <<294e533a-0cd8-417f-b83c-f40c2ebb8ed9@default>
[not found] ` <<87in6itj6c.fsf@gmail.com>
[not found] ` <<1e768b88-46ea-4e55-9403-2ce27d1cc63c@default>
[not found] ` <<83wouyxegg.fsf@gnu.org>
2018-06-17 4:20 ` Drew Adams
2018-06-17 5:43 ` Eli Zaretskii
2018-06-17 7:53 ` martin rudalics
[not found] <<<65951719-2046-44e9-8946-692a7a15d6d0@default>
[not found] ` <<<837emyzofh.fsf@gnu.org>
[not found] ` <<<294e533a-0cd8-417f-b83c-f40c2ebb8ed9@default>
[not found] ` <<<87in6itj6c.fsf@gmail.com>
[not found] ` <<<1e768b88-46ea-4e55-9403-2ce27d1cc63c@default>
[not found] ` <<<83wouyxegg.fsf@gnu.org>
[not found] ` <<18382c51-ad2f-499a-a6d7-02e802abb908@default>
[not found] ` <<83po0qx915.fsf@gnu.org>
2018-06-17 14:22 ` Drew Adams
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=1e768b88-46ea-4e55-9403-2ce27d1cc63c@default \
--to=drew.adams@oracle.com \
--cc=31858@debbugs.gnu.org \
--cc=npostavs@gmail.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).