emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rename "window" to "pane" (after Emacs 27)


From: Stefan Kangas
Subject: Rename "window" to "pane" (after Emacs 27)
Date: Tue, 29 Oct 2019 00:07:33 +0100

In 2014, there was a discussion about renaming "window" to "pane".
The current terminology dates back to the early 1980's, and while it's
unfortunate that other editors released since have adopted different
terminology, I believe it's time to admit defeat.  What we call a
"frame" is known as a "window" to 99.9 % of our new users, and to make
things worse we use "window" to describe something else entirely.

See the discussion here:
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00532.html
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00496.html
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00610.html
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00555.html

In that discussion, Stefan Monnier wrote (quoting RMS):
>> Conceivably we could rename "window" to "pane" and "frame" to "window".
>> I think the two renamings would have to be done in two different releases,
>> perhaps a year or two apart.
> Yup, it'd have to be a many-steps process:
> - first, rename "window" to "pane"
> - then rename "frame" to "window" (so frames would have 3 names:
>   screens, frames, and windows; tho admittedly we did finally get rid of
>   the "screen" aliases a few years ago).
>
> With a distinction between the Texinfo+docstring level and the Elisp
> code level.
>
> At the Lisp level, after renaming selected-window to selected-pane, we'd
> have to wait for the selected-window compatibility alias to disappear
> before we can rename selected-frame to selected-window.  I'd estimate
> that getting rid of the selected-window compatibility alias would take at
> least 20 years.
>
> This said, the "what you call a window is called a frame" is not nearly
> as problematic as "what we call window is not what you think", so maybe
> renaming "window" to "pane" would get us most of the benefit.
>
> So maybe the first step is the only one that really matters, and maybe
> my grand children can consider the second step when their time comes.
>
> I'm not sure how much change that represents, but if someone wants to
> take a stab at it... I'd be interested to see what it looks like.

I'd like to volunteer to take a stab at the first part here, namely
renaming "window" to "pane".

I've thought about this for a while, and I don't think the changes
involved are unfeasible.  I believe a realistic plan might look
something like this:

1. Change the names of the Lisp level functions to be named "window"
   instead of "pane" in window.c and window.el.  Make the old names
   into defaliases.  Update calls in Emacs to use the new names.  (I'm
   not sure if it would make sense to rename "window.{c,el}" to
   "pane.{c,el}" given how that makes it harder to browse Git
   history.)

2. Update elisp and emacs manual to introduce "pane" as a synonym for
   "window".  Make it clear that "pane" is the new and preferred
   terminology, but that old code and documentation might use "window"
   to mean the same thing.

3. Update doc strings of all functions changed above to talk about
   panes instead of windows.

I think this could be done in a feature branch, and, if the experiment
looks good, maybe we could considering merging it for Emacs 28.

I'd suggest to *not* do the following as part of the above initial plan:

- Update the C level code to use the new "pane" terminology.
- Update the Lisp code to internally only refer to "panes" (e.g. in
  let-bindings)
- Rename functions outside of window.el or window.c (OTOH, there's
  only ~500 of them, so maybe it's feasible?)
- Update all doc strings of all functions in Emacs where "window"
  shows up.
- Mark the above aliases obsolete.  (We could do that later.)

The excluded points would of course, in the context of a rename, make
sense to do eventually.  I believe they are too big tasks to do in a
single feature branch (perhaps we could do parts).  I'd therefore
suggest to first introduce the new terminology as the preferred one,
merge that, and then make these other changes incrementally over time.

(BTW, I count 56.480 hits for "window" in the tree, excluding
ChangeLogs, and presumably including a bunch of false positives for
window system, etc.)

Thoughts?

Best regards,
Stefan Kangas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]