unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Emacs developers <emacs-devel@gnu.org>
Subject: Rename "window" to "pane" (after Emacs 27)
Date: Tue, 29 Oct 2019 00:07:33 +0100	[thread overview]
Message-ID: <CADwFkmkZ6RPrYSrTpM9woTVMG=cH7_iMmvn6Mw+JykZPcEQQEw@mail.gmail.com> (raw)

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	other threads:[~2019-10-28 23:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 23:07 Stefan Kangas [this message]
2019-10-29  0:28 ` Rename "window" to "pane" (after Emacs 27) Filipp Gunbin
2019-10-29  1:55   ` Stefan Kangas
2019-10-30 17:29 ` Eli Zaretskii
2019-10-31  2:07 ` Richard Stallman
2020-03-31 18:50   ` Bruno Félix Rezende Ribeiro
2020-04-01  2:07     ` Richard Stallman
2020-04-01 12:03       ` Stefan Kangas
2020-04-01 14:56         ` Drew Adams
2020-04-01 15:13           ` Stefan Monnier
2020-04-01 17:04             ` Stefan Kangas
2020-04-01 17:30               ` Drew Adams
2020-04-02  2:34                 ` Richard Stallman
2020-04-02  4:51                   ` Jean-Christophe Helary
2020-04-03  2:52                     ` Richard Stallman
2020-04-01 15:25           ` Juanma Barranquero
2020-04-03 17:59           ` Sam Steingold
2020-04-03 18:34             ` Drew Adams
2020-04-03 18:53               ` Dmitry Gutov
2020-04-03 18:56                 ` Drew Adams
2020-04-03 18:54             ` Dmitry Gutov
2020-04-08 15:34               ` Sam Steingold
2020-04-08 17:29                 ` Dmitry Gutov
2020-04-02  2:31         ` Richard Stallman
2020-04-02  2:31         ` Richard Stallman

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='CADwFkmkZ6RPrYSrTpM9woTVMG=cH7_iMmvn6Mw+JykZPcEQQEw@mail.gmail.com' \
    --to=stefan@marxist.se \
    --cc=emacs-devel@gnu.org \
    /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).