Change terminology to better align users’ experience with modern GUIs

Change terminology to better align users’ experience with modern GUIs

[조성빈]

Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs? 

For example, `window' and `buffer' in emacs is more meaningful when explained as `pane' or `document'.

Especially the term `window' is a frequent source of confusion to Emacs newcomers which confuse them to `frame'.

IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.

Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

(Sorry about my bad English skills :-()

Re: Change terminology to better align users’ experience with modern GUIs

[Jean Louis]

* 조성빈 <pcr910303@icloud.com> [2019-07-23 08:47]:
> Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs? 
> 
> For example, `window' and `buffer' in emacs is more meaningful when
> explained as `pane' or `document'.

One word may have different definitions, right?

The Emacs manual explains the definitions.

I understand your viewpoint, you learned some other definitions for
same words and now you face little confusion. But imagine how many
people are there, so many of them would come from random environments
and would be faced with new definitions, so it would not be feasible
to change definitions to satisfy each particular wish, but I know that
changes and modifications are made by Emacs developers whenever it
benefits the majority.

In Emacs `buffer' is not necessarily connected to any file
document. Do you know?

> Especially the term `window' is a frequent source of confusion to
> Emacs newcomers which confuse them to `frame'.

Me not sure about that. I did not have confusion since 1999, since I
started using Emacs and stopped using that other system. But I did
take my time to read the books and manuals, and there were too many
new definitions of commands and terminology in the GNU/Linux system.

So facing the new terminology ALWAYS take place when learning some new
subject.

I hope that you can generally understand the situation. It applies in
every subject, not only computing.

When a new student in mining university learns definition of a
"sample", he cannot just try to adapt it to his previous understanding
of it, but he shall rather learn the new definition and apply it
properly in the context how and where it is used.

The word `sample' may be small part of something inteded as
representative of the whole (reference Wordnet). It could be a bite of
watermelon before its purchase.

But in mining, the word sample has quite different definition such as
"collection of fragments or pieces from a deposit which contains
exactly the same minerals in exactly the same proportions as they
exist in the deposit".

While it would be easier for student to simply go on with those known
definitions, it would create disaster in the subject of mining if his
definition of the word `sample' would be used.

That is why developers are pretty careful and try to find consensus
when making such modification.

> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
> However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.
> 
> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

I am also not native English speaker. It should be logical from
physical world that a window consists of frames and panes eventually.

Those definitions are different from Emacs terminology.

And I would leave it how it is. Do you know why?

Because Emacs is an important part of civilization and development of
many other apparently not related pieces of software.

It brings to easier understanding of its history. I have here a
document AI Memo 554, from October 22nd 1981, EMACS Manual for ITS
Users. Now I am not sure if they had any graphical environment at that
time.

That company that sells operating system Windows maybe started in the
same year some plans for it, but nothing was released until
1985. https://en.wikipedia.org/wiki/Microsoft_Windows#Early_versions

And in the EMACS Manual for ITS Users the words "windows" are
mentioned.

What if they did not use graphical system? Then it was a console or
terminal based application. Monitor would not be considered a window
so that screen tilings become pane.

I think that logic of "window" comes from the console or terminal
based operation.

And Emacs is widely used through terminal modes, so changing
terminology would break the logic for those users.

Jean

Re: Change terminology to better align users’ experience with modern GUIs

[조성빈]

> 2019. 7. 23. 오후 6:37, Jean Louis <bugs@gnu.support> 작성:
> 
> * 조성빈 <pcr910303@icloud.com> [2019-07-23 08:47]:
>> Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs? 
>> 
>> For example, `window' and `buffer' in emacs is more meaningful when
>> explained as `pane' or `document'.
> 
> One word may have different definitions, right?
> 
> The Emacs manual explains the definitions.
> 
> I understand your viewpoint, you learned some other definitions for
> same words and now you face little confusion. But imagine how many
> people are there, so many of them would come from random environments
> and would be faced with new definitions, so it would not be feasible
> to change definitions to satisfy each particular wish, but I know that
> changes and modifications are made by Emacs developers whenever it
> benefits the majority.

No, I’ve been using Emacs for about ~2 years, definitely not an Emacs guru
but done enough elisp that I understand what each term means.

> In Emacs `buffer' is not necessarily connected to any file
> document. Do you know?

I’m aware of that.
The reason why I was suggesting `document' is because that’s what other
editors usually call that; I would be totally fine for another kind of term
that’s meanings are clear to new users.

>> Especially the term `window' is a frequent source of confusion to
>> Emacs newcomers which confuse them to `frame'.
> 
> Me not sure about that. I did not have confusion since 1999, since I
> started using Emacs and stopped using that other system. But I did
> take my time to read the books and manuals, and there were too many
> new definitions of commands and terminology in the GNU/Linux system.
> 
> So facing the new terminology ALWAYS take place when learning some new
> subject.

Yes, it is true. When learning a new subject (especially when it comes 
to emacs) people should look forwards to learn new terminology.
However, it might be good practice to lower the barriers to approach Emacs
to a lot of people, considering that the majority of people who are using
computers have used graphical window systems.

>> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
>> However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.
>> 
>> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.
> 
> I am also not native English speaker. It should be logical from
> physical world that a window consists of frames and panes eventually.
> 
> Those definitions are different from Emacs terminology.
> 
> And I would leave it how it is. Do you know why?
> 
> Because Emacs is an important part of civilization and development of
> many other apparently not related pieces of software.

Because Emacs is an important part of civilization and development,
it might be better to adopt with the ‘outer world’ so that it can keep
gathering people.

> It brings to easier understanding of its history. I have here a
> document AI Memo 554, from October 22nd 1981, EMACS Manual for ITS
> Users. Now I am not sure if they had any graphical environment at that
> time.
> 
> That company that sells operating system Windows maybe started in the
> same year some plans for it, but nothing was released until
> 1985. https://en.wikipedia.org/wiki/Microsoft_Windows#Early_versions
> 
> And in the EMACS Manual for ITS Users the words "windows" are
> mentioned.

I understand the ‘why’ part of the original terminology; however, while
ITS has been discontinued for a long time, Emacs is used in the 21th
century where windowing systems are common (the majority).
Updating the terminology in a way that doesn’t interfere with the original
ones doesn’t harm IMO.

> What if they did not use graphical system? Then it was a console or
> terminal based application. Monitor would not be considered a window
> so that screen tilings become pane.

I’m not sure if the term `pane' implies that, for example people use 
the terminology `pane' in tmux, a terminal multiplexer.

> I think that logic of "window" comes from the console or terminal
> based operation.
> 
> And Emacs is widely used through terminal modes, so changing
> terminology would break the logic for those users.

While I know such people who use Emacs exclusively in terminals, most of them
have used/use window systems; they are very familiar with the usual `window’
terminology in general.
IMHO, the change of terminology wouldn’t be an issue to terminal users as the
terminology `pane’ also makes sense in terminals.

> Jean
> 

Re: Change terminology to better align users’ experience with modern GUIs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Tue, Jul 23, 2019 at 03:46:31PM +0900, 조성빈 wrote:
> Is there any intent or interest in updating the terminology
> of Emacs documentation/function names to better align users’
> experience with modern GUIs? 

Patience, young padovan :-)

Emacs has a working and dedicated community. If you just enter
through the door and say "Hello, everybody: how about we change
all names of things, like, now?"... how do you think people
will react?

Nevertheless you do have a strong point: the Emacs jargon, evolved
over a long time (few software packages in productive usage can look
back on thirty years of history) definitely poses a barrier to entry
for newcomers. Nobody wants that, thus constructive proposals to
change that are, I'm sure, welcome.

Change in Emacs is gradual (but still can be radical [1]), this
is a thing many of its users appreciate highly (I do, for one:
Emacs is one of my main tools, and I can afford to live on the
bleeding edge and compile for me the "newest Emacs" every week
or so. I wouldn't dare to do that with most other software out
there)!

So a good strategy, if you're really hot & willing to change
things would be to grab the documentation, and perhaps write
a companion to the documentation "Glossary" (let's call it
"Anti-Glossary" which translates "current" terms into the
Emacs terminology. So someone searching for "window", "pane",
"cursor", etc. has a chance to hit on the relevant documentation.

A next step might be to cross-index those "current" terms
with the "traditional" ones.

Whether you manage to convince enough people to really change
the language is anyone's guess, but you can start some steps
into that general direction.

P.S: Sorry if this mail comes across as somewhat... condescending.
This is not my intention at all! If that's the case, it is more
due to my inability to put things shortly and clearly.

Sorry for that.

Cheers

[1] I'd highly recommend reading
    https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
    It's only about the Lisp part of Emacs but gives an impression
    on how much has happened over time.

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Change terminology to better align users’ experience with modern GUIs

[Noam Postavsky]

On Tue, 23 Jul 2019 at 02:46, 조성빈 <pcr910303@icloud.com> wrote:

> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.

I don't see how that would even be possible.

> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

This could be helpful, but there are a *lot* of function names using
'window'. That means adding a lot of aliases for backwards
compatibility.

Re: Change terminology to better align users’ experience with modern GUIs

[Stefan Monnier]

>> IMO in my ideal world, there should be no division between `window' and
>> `buffer', the difference should be abstracted away so that users don’t
>> have to know the `window' notion at all.
> I don't see how that would even be possible.

Indeed.  A given window can show display different buffers at different
times, and a buffer can be displayed in any number of buffers at any one
time, so the two are really quite different.

>> Changing the `window' term to `pane' or something else seems like
>> a low-hanging fruit for people who would like to try using Emacs; I’m
>> interested/curious on other people’s opinions about this.
> This could be helpful, but there are a *lot* of function names using
> 'window'. That means adding a lot of aliases for backwards
> compatibility.

Yes, we discussed doing such a change a few years back (renaming window
to pane, and then renaming frame to window), but since those names
appear as part of functions's and variables's names, it implies
a massive renaming.  In order not to break external packages and users's
configs, the old names would still have to be preserved as aliases for
many years (meaning that there would need to be many years between the
renaming of windows to panes and the subsequent renaming of frames to
windows).

I think "many years" above can be estimated at about of 10 years (there
are still several important packages which consider it important to
be compatible with Emacs<23 and Emacs-23 was released 10 years ago).

So the way I see it, we're talking about 20 years of transition.
That makes "pane" rhyme with "pain".


        Stefan

Re: Change terminology to better align users’ experience with modern GUIs

[MBR]

I see this as the Emacs equivalent to the efforts to get the U.S. to 
switch from the English system of measurement to the Metric system.  And 
we all know how well that has gone.

Once a community has been using core terminology for an extended period 
of time, the only way to change it is to completely replace the members 
of the community.  And doing that would kill Emacs itself, which would 
make the notion of changing the terminology irrelevant.

    Mark Rosenthal

On 7/23/19 9:00 AM, Stefan Monnier wrote:
>>> IMO in my ideal world, there should be no division between `window' and
>>> `buffer', the difference should be abstracted away so that users don’t
>>> have to know the `window' notion at all.
>> I don't see how that would even be possible.
> Indeed.  A given window can show display different buffers at different
> times, and a buffer can be displayed in any number of buffers at any one
> time, so the two are really quite different.
>
>>> Changing the `window' term to `pane' or something else seems like
>>> a low-hanging fruit for people who would like to try using Emacs; I’m
>>> interested/curious on other people’s opinions about this.
>> This could be helpful, but there are a *lot* of function names using
>> 'window'. That means adding a lot of aliases for backwards
>> compatibility.
> Yes, we discussed doing such a change a few years back (renaming window
> to pane, and then renaming frame to window), but since those names
> appear as part of functions's and variables's names, it implies
> a massive renaming.  In order not to break external packages and users's
> configs, the old names would still have to be preserved as aliases for
> many years (meaning that there would need to be many years between the
> renaming of windows to panes and the subsequent renaming of frames to
> windows).
>
> I think "many years" above can be estimated at about of 10 years (there
> are still several important packages which consider it important to
> be compatible with Emacs<23 and Emacs-23 was released 10 years ago).
>
> So the way I see it, we're talking about 20 years of transition.
> That makes "pane" rhyme with "pain".
>
>
>          Stefan
>
>
>

Re: Change terminology to better align users’ experience with modern GUIs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Tue, Jul 23, 2019 at 09:00:03AM -0400, Stefan Monnier wrote:

[...]

> Yes, we discussed doing such a change a few years back (renaming window
> to pane [...]

> I think "many years" above can be estimated at about of 10 years [...]

And who knows what the "terminology du jour" will be in 10 years. This
industry is currently very much fad-driven.

So imagine Emacs (painfully) changes window -> pane and frame -> window,
and the dominant technology talks about "trays" and "vanes". Or something.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Change terminology to better align users’ experience with modern GUIs

[Noam Postavsky]

On Tue, 23 Jul 2019 at 09:40, <tomas@tuxteam.de> wrote:

> And who knows what the "terminology du jour" will be in 10 years. This
> industry is currently very much fad-driven.

The term "window" has been pretty long-lived.

> So imagine Emacs (painfully) changes window -> pane and frame -> window,
> and the dominant technology talks about "trays" and "vanes". Or something.

That would still be better, because we wouldn't have the Emacs-window
vs Other-Gui-window meaning conflict.

Re: Change terminology to better align users’ experience with modern GUIs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Tue, Jul 23, 2019 at 09:46:39AM -0400, Noam Postavsky wrote:
> On Tue, 23 Jul 2019 at 09:40, <tomas@tuxteam.de> wrote:
> 
> > And who knows what the "terminology du jour" will be in 10 years. This
> > industry is currently very much fad-driven.
> 
> The term "window" has been pretty long-lived.

That's true. Perhaps (?) it was in use already with PARC's Alto, so around
1973.

But I think at that time terminology wasn't so clear. "Windows" were
also of the non-overlapping kind (think tiling window manager these
days), i.e. exactly what Emacs is doing :-)

> > So imagine Emacs (painfully) changes window -> pane and frame -> window,
> > and the dominant technology talks about "trays" and "vanes". Or something.
> 
> That would still be better, because we wouldn't have the Emacs-window
> vs Other-Gui-window meaning conflict.

:-)

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Change terminology to better align users’ experience with modern GUIs

[Stefan Monnier]

>> I think "many years" above can be estimated at about of 10 years [...]
> And who knows what the "terminology du jour" will be in 10 years.

OTOH Emacs-24 was released in 2012, so by 2022 the vast majority of
packages will depend on this version of Emacs, which came with
package.el, so we can expect that by then all those packages will be
distributed via ELPA.

That means packages could start using the "pane" terminology with
Emacs-24 already, assuming we provide a forward-compatibility package
(like I did for cl-lib) adding the "pane" aliases.

That might help speed up the transition a bit.


        Stefan

Re: Change terminology to better align users’ experience with modern GUIs

[Eli Zaretskii]

> Date: Tue, 23 Jul 2019 12:44:48 +0200
> From: <tomas@tuxteam.de>
> 
> So a good strategy, if you're really hot & willing to change
> things would be to grab the documentation, and perhaps write
> a companion to the documentation "Glossary" (let's call it
> "Anti-Glossary" which translates "current" terms into the
> Emacs terminology. So someone searching for "window", "pane",
> "cursor", etc. has a chance to hit on the relevant documentation.

There's no need for "Anti-Glossary".  Our Glossary already includes
some terminology from "other applications", such as "cut", "paste",
and "syntax highlighting".  It could easily accommodate a few more.

> A next step might be to cross-index those "current" terms
> with the "traditional" ones.

These are already in the Glossary.

Re: Change terminology to better align users’ experience with modern GUIs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Tue, Jul 23, 2019 at 05:43:28PM +0300, Eli Zaretskii wrote:

[...]

> There's no need for "Anti-Glossary" [...]

> > A next step might be to cross-index those "current" terms
> > with the "traditional" ones.
> 
> These are already in the Glossary.

Thanks for the clarifications, Eli. Still, I feel that someone
"entering" this world might be a bit... lost. Obviously some
phantasy is needed to come up with a helpful scheme which doesn't
bring about too much collateral damage?

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Change terminology to better align users’ experience with modern GUIs

[Eli Zaretskii]

> Date: Tue, 23 Jul 2019 18:15:56 +0200
> From: <tomas@tuxteam.de>
> 
> > There's no need for "Anti-Glossary" [...]
> 
> > > A next step might be to cross-index those "current" terms
> > > with the "traditional" ones.
> > 
> > These are already in the Glossary.
> 
> Thanks for the clarifications, Eli. Still, I feel that someone
> "entering" this world might be a bit... lost. Obviously some
> phantasy is needed to come up with a helpful scheme which doesn't
> bring about too much collateral damage?

Sure.  I just wanted to point out that if we want to add to the
Glossary a few more of the widespread terms for which Emacs has its
own names, we could.

Re: Change terminology to better align users’ experience with modern GUIs

[Gerhard Wolfstieg]

     Hallo all together!

Before exchanging the words, could you please reconsider, why the
people behind emacs called the visible work area „window“ – and not the
whole thing? For me it is stupendous logic.

Please don’t give up the best while the modern one isn’t it. (What is
modern?)

     Grüße, Gerhard

Re: Change terminology to better align users’ experience with modern GUIs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Tue, Jul 23, 2019 at 07:03:55PM +0200, Gerhard Wolfstieg wrote:
>      Hallo all together!
> 
> Before exchanging the words, could you please reconsider, why the
> people behind emacs called the visible work area „window“ – and not the
> whole thing? For me it is stupendous logic.
> 
> Please don’t give up the best while the modern one isn’t it. (What is
> modern?)

Still there is merit in easing access to newcomers. So the idea is
good and shouldn't be dismissed off-hand.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Change terminology to better align users’ experience with modern GUIs

[Stefan Monnier]

> Before exchanging the words, could you please reconsider, why the
> people behind emacs called the visible work area „window“ – and not the
> whole thing? For me it is stupendous logic.

Not sure what was the "logic" or even if any particular terminology here
is more "logical", but FWIW, Emacs's notion of "window" was inherited
from earlier Emacsen (ITS Emacs and Multics Emacs at least had these
kinds of "panes" and called them "windows": these were before the days
of GUIs).

GNU Emacs and the X Window System were started at around the same time,
so Emacs could have used the "new" terminology I guess, but it would
have had to be "forward looking", whereas it took it another 10 years
(i.e. until Emacs-19) before it started to break out of the "text
terminal" mold.


        Stefan

Re: Change terminology to better align users’ experience with modern GUIs

[Emanuel Berg]

tomas wrote:

> Emacs has a working and dedicated community.
> If you just enter through the door and say
> "Hello, everybody: how about we change all
> names of things, like, now?"... how do you
> think people will react?

Wait, I think I know the answer to this
question! It is "exactly in the way they
reacted", yes?

> Emacs jargon, evolved over a long time (few
> software packages in productive usage can
> look back on thirty years of history)
> definitely poses a barrier to entry
> for newcomers.

We have heard many versions of this tale,
namely that Emacs is difficult to learn, and
difficult to use, and this scares new users
away; and if those were only more easy to do,
more people would!

I don't know how much truth there is to any of
that, to be honest.

And, unless I'm brained damaged by too much
Emacs, there isn't that much "Emacs jargon",
is it?

> So a good strategy, if you're really hot &
> willing to change things would be to grab the
> documentation, and perhaps write a companion
> to the documentation "Glossary" (let's call
> it "Anti-Glossary" which translates "current"
> terms into the Emacs terminology. So someone
> searching for "window", "pane", "cursor",
> etc. has a chance to hit on the
> relevant documentation.

Well, one can do that for sure, but it comes
down to a policy decision. I can't say I care
if there is a terminology mismatch from the
GUI world to the Emacs ditto, but in general,
obviously it is good to strive at a unified
terminology, while it can be done practically
(perhaps some workaround must be put in place,
so not to break code already written but not
maintained, code which is outside of the core
Emacs binary).

> P.S: Sorry if this mail comes across as
> somewhat... condescending. This is not my
> intention at all! If that's the case, it is
> more due to my inability to put things
> shortly and clearly.

Nah, stop it.

> Sorry for that.

It's OK.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Change terminology to better align users’ experience with modern GUIs

[Emanuel Berg]

Noam Postavsky wrote:

> This could be helpful, but there are a *lot*
> of function names using 'window'. That means
> adding a lot of aliases for
> backwards compatibility.

Well, if one can add one alias, one can almost
just as easily add two, etc etc.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Change terminology to better align users’ experience with modern GUIs

[Emanuel Berg]

tomas wrote:

> And who knows what the "terminology du jour"
> will be in 10 years. This industry is
> currently very much fad-driven.
>
> So imagine Emacs (painfully) changes window
> -> pane and frame -> window, and the dominant
> technology talks about "trays" and "vanes".
> Or something.

Another scenario that the EFI (The Emacs Future
Institue) has considered is that an asteroid
with an estimated diameter of fourteen
kilometers will smash into the Far East, along
with multiple fragments dislodged by the
atmosphere on entry. The impact will shake the
planet, blow away the ozone layer, and even
tilt the earth's axis. The vast meteorite will
carve out a giant crater, 230 kilometers in
diameter, and kick massive amounts of dust into
the stratosphere. Thick clouds will encompass
the entire planet, and soon the earth will
freeze over. Winter will come... the long, cold
Impact Winter!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Change terminology to better align users’ experience with modern GUIs

[Emanuel Berg]

tomas wrote:

> Thanks for the clarifications, Eli. Still,
> I feel that someone "entering" this world
> might be a bit... lost.

[Note: The last paragraph is the interesting
 part of this post! And not only because it is
 about me :) ]

First, I think people who come to a piece of
software like ours aren't beginners or are
lacking in self-confidence when it comes to
computers or learning new things in general.

Second, speaking even more broadly, I think
that changing small details "here" won't bring
about huge changes "there". If people aren't
coming to us, it doesn't matter if a window is
called a frame, and a pane is called a window.
Changing that won't make a difference, much
like changing the color of a sign above
a derailed business won't make customers
suddenly line up the pavement.

Why people came to the software at one time,
and why they don't do it now, if that indeed is
the case, is a better question, and I admit
I don't even have an educated guess.

I grew up with computers from when my age
consisted of a single digit, and they all had
GUIs, the first computer I ever saw was
a Mac Plus - with no fan and no HDD, and 800 KB
floppies which contained the OS as well as any
other software - not that there were a lot,
back then, at least not for the Mac. So while
it didn't have much, the OS, Finder, was a GUI
one. So it was even then all about GUIs and
when I started programming, by instinct, it was
with Visual Basic 5.0, so it was all GUIs there
as well! But when I started programming in
a more methodic way (altho it was still by
instinct to a large degree, I'd now say), by
that time I really didn't want anything to do
with GUIs - buttons, menus, the mouse...
I considered that - in general, because there
are exceptions like web browsing, GISs, FPSs,
and so one - I considered that to be using
a computer at a lower level, at the level of
the consumer oriented masses, that only cared
for services, multimedia, and games, not the
computer itself, if you will. Also, I wanted an
editor which I could tweak in exactly the way
I liked. All this came together with Emacs.
When I came here in particular, to what I now
call gmane.emacs.help, it felt like everyone
was older and more experienced than me. Now,
I don't know, maybe it just felt that way and
there were actually a lot of people coming to
the Emacs world about that time. Probably!
Also, I don't know if their reasons were the
same as mine. Because if several people came
around then, and several people came for the
same reasons, that'd mean, that those reason
don't hold any appeal to today's folks, and
that's why they aren't coming. And if they
don't, well all the more reason to believe that
yeah, changing frame to window and window to
pane won't change anything from that
side'a things.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal