From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dave@boostpro.com, martin rudalics <rudalics@gmx.at>,
emacs-devel@gnu.org
Subject: Re: Subwindow terminology
Date: Mon, 07 Nov 2011 08:17:59 +0900 [thread overview]
Message-ID: <874nygon6g.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <E1RN0d1-0006gS-H3@fencepost.gnu.org>
Eli Zaretskii writes:
> In order to make this discussion more productive, and avoid requesting
> Martin to repeat things he already wrote, I suggest that people read
> the discussions in bugs #9875 and #9873, and take it from there.
No, I'll just deal with the fallout when XEmacs needs to sync to this
ill-conceived mess. Martin doesn't write anything about why history
of a window tree matters to Lisp programmers, but instead writes many
things like
But since I apparently failed to convey the semantics of this
variable in the Elisp manual, someone else will have to take care
of writing such a description.
and
> Why do you need to talk about subwindows at all?
Because I didn't give this a thought yet ;-)
If he needs to repeat those statements at this point, y'all are up to
your necks in the Big Muddy.
And reading *all* of both bugs doesn't explain why history of a window
tree matters, except to Martin personally because he's the one who has
to make sure invariants are maintained across operations on window
trees. But the rest of us *using* the API are counting on him to get
those invariants right.
My suggestion for conformance to traditional nomenclature for windows
and established nomenclature for trees (terms being defined are
*emphasized*):
(1) A *window* is a rectangular area entirely included in a frame
in which a buffer can be displayed.
(2) Windows are *live* when they are leaf nodes in a "live" frame.
Otherwise they are *dead*. The behavior of dead windows is of
interest only to implementors (with the single exception of
windows resurrected by configuration restoration).
(3) Windows are organized into window groups. Each *window group* is
a one-dimensional contiguous array of conformable windows or
window groups. *Conformable* means that they all have the same
dimension in the direction perpendicular to the array, and that
where the sides touch, the corners coincide. (I'm not wedded to
the word "conformable".) Note that this means that every window
group covers a rectangle. Window groups are referred to as
"window rows" or "window columns" (*not* "horizontal" or
"vertical") when the direction of the array is important.
I'm not wedded to the term "window group", but it seems like it
would make sense to Lisp programmers who neither need nor want to
know about how window configurations are implemented. "Window
node" might do if emphasizing the tree nature of window
configurations seems like a good idea, with a "window" being a
special kind of "window node" that can display a buffer.
I don't know if the new implementation of window configurations
requires that groups be maximal, ie, prohibits
+---+---+---+---+
| 1 | 1 | 2 | 2 |
+---+---+---+---+
where "1" and "2" label window group membership. Whether it does
or not should be mentioned.
(4) Each window group is therefore the root of a *window tree*.
(Technically, a "window group tree", but that's a bit heavy, and I
agree with Eli that giving people the right idea is more important
than full precision in description.)
(5) A *window configuration* is a window tree that fills the whole
frame.
(6) The words *root*, *leaf*, *sibling*, *child*, *parent*,
*ancestor*, and *descendant* take their usual meanings in
discussion of trees.
Window APIs have a WINDOW argument. Unfortunately, this means that
where appropriate, older APIs that now operate on window groups as
well as windows need the sentence:
From Emacs 24, WINDOW may be a live window or window group.
or similar in their docstrings. The Lispref can establish a
convention to avoid such repetition.
Any place you feel a *need* to use the term "subwindow" needs more
thought about what you're actually doing. :-) (Of course I have an
ulterior motive here, in that XEmacs uses the term "subwindow" for a
completely different kind of object, a "native widget", but I think
that sentence is nevertheless true.)
next prev parent reply other threads:[~2011-11-06 23:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-05 4:36 Subwindow terminology Chong Yidong
2011-11-05 11:23 ` martin rudalics
2011-11-05 12:50 ` Stephen J. Turnbull
2011-11-05 13:28 ` martin rudalics
2011-11-05 13:36 ` Stephen J. Turnbull
2011-11-05 15:05 ` martin rudalics
2011-11-05 16:54 ` Stephen J. Turnbull
2011-11-05 20:31 ` Dave Abrahams
2011-11-06 8:50 ` martin rudalics
2011-11-06 9:16 ` Dave Abrahams
2011-11-06 10:59 ` martin rudalics
2011-11-06 11:36 ` Dave Abrahams
2011-11-06 13:24 ` martin rudalics
2011-11-06 9:26 ` Stephen J. Turnbull
2011-11-06 10:59 ` martin rudalics
2011-11-06 11:11 ` Eli Zaretskii
2011-11-06 23:17 ` Stephen J. Turnbull [this message]
2011-11-07 10:18 ` martin rudalics
2011-11-08 9:55 ` Chong Yidong
2011-11-06 22:15 ` Stephen J. Turnbull
2011-11-07 10:17 ` martin rudalics
2011-11-07 10:16 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874nygon6g.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=dave@boostpro.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.