* Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 6:21 ` Lars Magne Ingebrigtsen
@ 2014-01-07 7:30 ` Drew Adams
2014-01-07 10:30 ` Lennart Borgman
2014-01-07 11:13 ` Stephen J. Turnbull
2014-01-07 10:30 ` Apologia for bzr Jose E. Marchesi
1 sibling, 2 replies; 47+ messages in thread
From: Drew Adams @ 2014-01-07 7:30 UTC (permalink / raw
To: Lars Magne Ingebrigtsen, Stefan Monnier
Cc: esr, toby-dated-1389972095.0848dd, Lennart Borgman,
Richard Stallman, emacs-devel
> > 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.
>
> I think you're right there. If we just get rid of the word
> "window", I think that'll fix most confusions.
What confusion? Is there really a problem? Are you sure?
I've been dealing with newbie Emacs questions and confusion
for as long as most of you, and I don't think I have ever
encountered a user who had difficulting understanding what
we mean, once the terms are presented.
IOW, any contact at all with either the Emacs docs or a quick
Q & A has always answered any user questions I've come across
in this regard. I have never, ever, encountered any
"confusion" here. There is sometimes confusion elsewhere
(menu structure, keymaps, font-lock-keywords...), but no
confusion about windows and frames, once the terms are
explained. No confusion, just initial ignorance, which is
not the same thing and which is easily remedied.
Seriously, have any of you encounted a user who could not
understand what an Emacs window and frame are? Ever?
Really?
It's a faux probleme. It says more about you who see it as
a problem than it does about any potential Emacs newbies.
And you ain't gonna get no mileage out of making a big
attempt to clothe Emacs in terminology the Emacs-ignorant
will immediately recognize. There really is a wolf under
those sheepskins - Emacs is a different beast. Everything
worth its salt has its own jargon. Including Emacs.
Gratuitous differences in terminology for identical things
are something else. But (a) that is rare (the Emacs thingies
are not really the same), and (b) even then it is not
important to toe the line. Especially if the things are
identical, it is easy to learn new terms for them.
Examples of exceptional things that are identical in Emacs,
or nearly so, are "cut" and "paste" operations. And as
others have already said, it is enough to point out the
Emacs terminology and the correspondences (when there are
close correspondences and not just faux amis) - which we
already do, AFAIK.
If you think that initiation into the ways and jargon of
Emacs is just too darn hard for today's kiddies, I'd say
you're not only pandering (demagogy), you're selling the
kiddies short. Have confidence. You learned Emacs, and
no, you ain't no smarter or tougher than they are.
(Now if we just get rid of Emacs, I think that would take
care of most confusion...)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 7:30 ` Emacs terminology (not again!?) [was: Apologia for bzr] Drew Adams
@ 2014-01-07 10:30 ` Lennart Borgman
2014-01-07 18:05 ` Joel Mccracken
2014-01-07 11:13 ` Stephen J. Turnbull
1 sibling, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 10:30 UTC (permalink / raw
To: Drew Adams
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> What confusion? Is there really a problem? Are you sure?
>
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
>
> The difficulty is not understanding, but rather remembering. "What a h-ll
did they call that?"
[-- Attachment #2: Type: text/html, Size: 1061 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 7:30 ` Emacs terminology (not again!?) [was: Apologia for bzr] Drew Adams
2014-01-07 10:30 ` Lennart Borgman
@ 2014-01-07 11:13 ` Stephen J. Turnbull
2014-01-07 11:27 ` Lennart Borgman
1 sibling, 1 reply; 47+ messages in thread
From: Stephen J. Turnbull @ 2014-01-07 11:13 UTC (permalink / raw
To: Drew Adams
Cc: Richard Stallman, toby-dated-1389972095.0848dd, Lennart Borgman,
emacs-devel, esr, Stefan Monnier, Lars Magne Ingebrigtsen
Drew Adams writes:
> > I think you're right there. If we just get rid of the word
> > "window", I think that'll fix most confusions.
>
> What confusion? Is there really a problem? Are you sure?
Agreed. The important disconnect is between windows and buffers, and
even that isn't so hard for users to figure out. I think people used
to recent browser interfaces will call buffers "tabs".
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 11:13 ` Stephen J. Turnbull
@ 2014-01-07 11:27 ` Lennart Borgman
2014-01-07 12:13 ` Yuri Khan
2014-01-07 14:07 ` Stephen J. Turnbull
0 siblings, 2 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 11:27 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen, Drew Adams
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
>
> Agreed. The important disconnect is between windows and buffers, and
> even that isn't so hard for users to figure out. I think people used
> to recent browser interfaces will call buffers "tabs".
>
I think that is a good illustration of how confusing different terms can
be... ;-)
"Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
for most new users.
[-- Attachment #2: Type: text/html, Size: 1081 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 11:27 ` Lennart Borgman
@ 2014-01-07 12:13 ` Yuri Khan
2014-01-07 14:07 ` Stephen J. Turnbull
1 sibling, 0 replies; 47+ messages in thread
From: Yuri Khan @ 2014-01-07 12:13 UTC (permalink / raw
To: Lennart Borgman
Cc: Toby Cubitt, Emacs-Devel devel, Eric Raymond, Stefan Monnier,
Lars Magne Ingebrigtsen, Stephen J. Turnbull, Drew Adams
On Tue, Jan 7, 2014 at 6:27 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> "Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
> for most new users.
+1.
The difficulty with Emacs that I had when I was a beginner Emacs user
and still have not completely gotten over, is the relationships
between buffers and windows.
In a typical $another_application, you have at the top level a window
or several windows. Each window may be split into panes, and each pane
may contain several tabs, each tab displaying a document. (In rare
cases, a tab may display a secondary view into a document that is also
displayed by another tab. Opening a secondary view is always a
conscious action on part of the user.) Closing the last view into a
document signals that the user is done with this document — this is
the time to ask any “would you like to save” questions. Otherwise, the
user is free to rearrange tabs between panes and windows. At every
point in time, there is a well-defined spatial position of each
document view — e.g. “the third tab in the upper pane of the window on
my left monitor”.
In Emacs, what you primarily have is a bunch of buffers which exist
without any permanent attachment with the UI. Then, you have frames
that may be split into windows, each window being a view into some
buffer. You cannot meaningfully talk about spatial positions of
buffers — they are essentially “everywhere” or “inside”. Or, if a
buffer is not displayed in any window, it’s “nowhere” and also
“inside”.
The model of Emacs is more flexible, but I find myself struggling with
it because I have to remember that there are hidden buffers and cannot
rely on the spatial model that my mind is accustomed to.
(Curiously, my other always-open application is Firefox that *does*
adhere to the spatial model. I end up opening a single window on each
monitor, and around a dozen tabs in each window. Then I have trouble
locating the tab I need since there are so many of them. So maybe the
problem surfaces when the number of entities exceeds my short-term
memory capacity, regardless of their organization.)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 11:27 ` Lennart Borgman
2014-01-07 12:13 ` Yuri Khan
@ 2014-01-07 14:07 ` Stephen J. Turnbull
2014-01-07 14:16 ` Lennart Borgman
1 sibling, 1 reply; 47+ messages in thread
From: Stephen J. Turnbull @ 2014-01-07 14:07 UTC (permalink / raw
To: Lennart Borgman
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen, Drew Adams
Lennart Borgman writes:
> On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>> Agreed. The important disconnect is between windows and buffers,
>> and even that isn't so hard for users to figure out. I think
>> people used to recent browser interfaces will call buffers "tabs".
> I think that is a good illustration of how confusing different
> terms can be... ;-) "Tabs" is a UI thing. Calling buffers "tabs"
> would be very, very confusing for most new users.
Agreed. I'm not suggesting that as Emacs terminology. I'm saying
that users are going to see buffers as ways to show different content
in the same (GUI) window just like tabs do.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 14:07 ` Stephen J. Turnbull
@ 2014-01-07 14:16 ` Lennart Borgman
0 siblings, 0 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 14:16 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen, Drew Adams
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Tue, Jan 7, 2014 at 3:07 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
> Lennart Borgman writes:
> > On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <
> stephen@xemacs.org> wrote:
>
> >> Agreed. The important disconnect is between windows and buffers,
> >> and even that isn't so hard for users to figure out. I think
> >> people used to recent browser interfaces will call buffers "tabs".
>
> > I think that is a good illustration of how confusing different
> > terms can be... ;-) "Tabs" is a UI thing. Calling buffers "tabs"
> > would be very, very confusing for most new users.
>
> Agreed. I'm not suggesting that as Emacs terminology. I'm saying
> that users are going to see buffers as ways to show different content
> in the same (GUI) window just like tabs do.
>
> I see. ;-)
In a way, yes. It is a very useful concept. And one of the few things I
think should be presented to new users. The rest should be so familiar so
they should be able to start without knowing more. (If they are just to
Notepad or something similar.
[-- Attachment #2: Type: text/html, Size: 2079 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 10:30 ` Lennart Borgman
@ 2014-01-07 18:05 ` Joel Mccracken
2014-01-07 19:06 ` Drew Adams
2014-01-07 19:37 ` David Kastrup
0 siblings, 2 replies; 47+ messages in thread
From: Joel Mccracken @ 2014-01-07 18:05 UTC (permalink / raw
To: Lennart Borgman
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen, Drew Adams
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
Beyond trying to remember, using current terminology is sends the message that Emacs is old, stubborn, and crufty, which is a problem when trying to introduce new users to Emacs.
On Jan 7, 2014, at 5:30 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> What confusion? Is there really a problem? Are you sure?
>
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
>
> The difficulty is not understanding, but rather remembering. "What a h-ll did they call that?"
>
[-- Attachment #2: Type: text/html, Size: 1673 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 18:05 ` Joel Mccracken
@ 2014-01-07 19:06 ` Drew Adams
2014-01-07 19:17 ` Lennart Borgman
2014-01-07 19:56 ` David Reitter
2014-01-07 19:37 ` David Kastrup
1 sibling, 2 replies; 47+ messages in thread
From: Drew Adams @ 2014-01-07 19:06 UTC (permalink / raw
To: Joel Mccracken, Lennart Borgman
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Lars Magne Ingebrigtsen
> Beyond trying to remember, using current terminology is sends
> the message that Emacs is old, stubborn, and crufty, which is a
> problem when trying to introduce new users to Emacs.
No, it does not. If Emacs were invented from scratch today, it
would still need its own jargon. Some of the particulars would
no doubt be different, but Emacs would still stand apart in both
behavior and terminology.
Emacs happens to be old. And it happens to be different.
Being different does not send a message that Emacs is old, or
stubborn, or crufty. Being old means that it is, well, old.
But that too does not send a message that it is stubborn or
crufty.
You are sending that message, by proposing that the terminology
be updated etc. Someone new to Emacs and aware of this kind of
discussion can be forgiven for getting the mistaken impression
that Emacs behavior is just the same as other apps but the
terminology is out-of-date and so makes learning it unnecessarily
difficult. That's the wrong message entirely - quite misleading.
The right takeaway for a new user is that learning Emacs is
learning something new and different - it is not your momma's
editor. And it rightfully has its own terminology, which you
had better learn also.
The Greek philosopher Proclus records that when Ptolemy asked
if there wasn't perhaps an easier way to learn Emacs than Emacs,
Euclid replied, "Sire, there is no royal road to Emacs."
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 19:06 ` Drew Adams
@ 2014-01-07 19:17 ` Lennart Borgman
2014-01-07 19:56 ` David Reitter
1 sibling, 0 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 19:17 UTC (permalink / raw
To: Drew Adams
Cc: Richard Stallman, Toby Cubitt, Emacs-Devel devel, Eric Raymond,
Stefan Monnier, Joel Mccracken, Lars Magne Ingebrigtsen
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
On Tue, Jan 7, 2014 at 8:06 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> The right takeaway for a new user is that learning Emacs is
> learning something new and different - it is not your momma's
> editor. And it rightfully has its own terminology, which you
> had better learn also.
>
>
Did not someone say it was his momma's editor? ;-)
I think you are taking your points too far. For me the problem is how to
make a good road into Emacs for new users. I want a feeling like "this is
what I am used to and now I am glad I discovered the new possibilities". It
should be both familiar and new at the same time.
> The Greek philosopher Proclus records that when Ptolemy asked
> if there wasn't perhaps an easier way to learn Emacs than Emacs,
> Euclid replied, "Sire, there is no royal road to Emacs."
>
There might be some translation error or misunderstanding there. ;-)
[-- Attachment #2: Type: text/html, Size: 1654 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 18:05 ` Joel Mccracken
2014-01-07 19:06 ` Drew Adams
@ 2014-01-07 19:37 ` David Kastrup
2014-01-07 19:50 ` Lennart Borgman
2014-01-08 3:41 ` Richard Stallman
1 sibling, 2 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-07 19:37 UTC (permalink / raw
To: emacs-devel
Joel Mccracken <mccracken.joel@gmail.com> writes:
> Beyond trying to remember, using current terminology is sends the
> message that Emacs is old, stubborn, and crufty, which is a problem
> when trying to introduce new users to Emacs.
Emacs _is_ one of the old great ones. You are trying to make Gandalf
more popular by plucking his nose hairs.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 19:37 ` David Kastrup
@ 2014-01-07 19:50 ` Lennart Borgman
2014-01-08 3:41 ` Richard Stallman
1 sibling, 0 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 19:50 UTC (permalink / raw
To: David Kastrup; +Cc: Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
On Tue, Jan 7, 2014 at 8:37 PM, David Kastrup <dak@gnu.org> wrote:
> Joel Mccracken <mccracken.joel@gmail.com> writes:
>
> > Beyond trying to remember, using current terminology is sends the
> > message that Emacs is old, stubborn, and crufty, which is a problem
> > when trying to introduce new users to Emacs.
>
> Emacs _is_ one of the old great ones. You are trying to make Gandalf
> more popular by plucking his nose hairs.
>
> The great thing lives in its power, not in the nose hairs. Just pick them.
;-)
[-- Attachment #2: Type: text/html, Size: 1408 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 19:06 ` Drew Adams
2014-01-07 19:17 ` Lennart Borgman
@ 2014-01-07 19:56 ` David Reitter
2014-01-07 20:31 ` Drew Adams
1 sibling, 1 reply; 47+ messages in thread
From: David Reitter @ 2014-01-07 19:56 UTC (permalink / raw
To: Drew Adams; +Cc: Emacs-Devel devel
On Jan 7, 2014, at 2:06 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Beyond trying to remember, using current terminology is sends
>> the message that Emacs is old, stubborn, and crufty, which is a
>> problem when trying to introduce new users to Emacs.
>
> No, it does not. If Emacs were invented from scratch today, it
> would still need its own jargon. Some of the particulars would
> no doubt be different, but Emacs would still stand apart in both
> behavior and terminology.
Yes, but the jargon would not conflict with widely used terminology. Would you really redefine a common word like "window", and invent another one referring to the established meaning of windows?
Other things are actually different, and different terms are appropriate. "Mark" comes to mind, or "major" and "minor" modes.
You're right in that Emacs is not yet another editor, and you want to send that message. But, don't people see this soon enough when they actually use it?
The UI experiment that I have been interested in with Aquamacs, is to allow people to gradually transition from a newbie user to a proficient one with high routinized sequences of actions. This is actually something that other editors and IDEs can't provide to the extent that Emacs does. Netbeans, Eclipse, Xcode - they're great IDEs and very integrated, and certainly useful for proficient users, but they're nowhere nearly as efficient as Emacs.
^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 19:56 ` David Reitter
@ 2014-01-07 20:31 ` Drew Adams
2014-01-07 20:42 ` Lennart Borgman
2014-01-10 2:12 ` David Reitter
0 siblings, 2 replies; 47+ messages in thread
From: Drew Adams @ 2014-01-07 20:31 UTC (permalink / raw
To: David Reitter; +Cc: Emacs-Devel devel
> > If Emacs were invented from scratch today, it
> > would still need its own jargon. Some of the particulars would
> > no doubt be different, but Emacs would still stand apart in both
> > behavior and terminology.
>
> Yes, but the jargon would not conflict with widely used terminology.
Preferably, yes; agreed. Other things being equal...
> Would you really redefine a common word like "window", and invent
> another one referring to the established meaning of windows?
No, I would not. This is what I meant by "Some of the particulars
would no doubt be different."
> Other things are actually different, and different terms are
> appropriate. "Mark" comes to mind, or "major" and "minor" modes.
Yes, in general. (Dunno about "mark", but let's not get into
particulars right now.)
> You're right in that Emacs is not yet another editor, and you want
> to send that message. But, don't people see this soon enough when
> they actually use it?
Yes. I am not suggesting that that message is not getting across.
You are mistaken that I feel a need to send that message. My point
was that Emacs behavior is different, and it necessarily has its
own terminology to some extent. That is not something to be wished
away or papered over.
> The UI experiment that I have been interested in with Aquamacs, is
> to allow people to gradually transition from a newbie user to a
> proficient one with high routinized sequences of actions. This is
> actually something that other editors and IDEs can't provide to the
> extent that Emacs does. Netbeans, Eclipse, Xcode - they're great
> IDEs and very integrated, and certainly useful for proficient users,
> but they're nowhere nearly as efficient as Emacs.
Concrete suggestions about that might well be helpful. So far,
the discussion has just rehashed previous ones. What you suggest
is not a bad goal, but the starting point should not be to short-sell
newbie Emacs users (not suggesting your approach does that; I don't
know). They are as bright as past newbies, no doubt.
Yes, they have more experience with other approaches that could
mislead them - Emacs is not often their first editor/UI. But that
does not mean they cannot "get" Emacs. What is true today, as it
always has been, is that some effort to learn is needed. You
cannot just pick up Emacs expecting it to do what you are used to,
without being disappointed or missing the boat.
One has only to look at the questions on a site such as
StackOverflow, not especially those about Emacs, but generally
(and apparently about PHP in particular), to see that some users
expect instant familiarity with a product without any effort - not
even a cursory look at the doc or a Google search. The SO site
leaders are continually lamenting the poor quality of (some)
questions and askers. Some people really do expect a royal road
to learning. Encouraging them in that does not help them or
anyone else.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 20:31 ` Drew Adams
@ 2014-01-07 20:42 ` Lennart Borgman
2014-01-10 2:12 ` David Reitter
1 sibling, 0 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-07 20:42 UTC (permalink / raw
To: Drew Adams; +Cc: David Reitter, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
On Tue, Jan 7, 2014 at 9:31 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search. The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers. Some people really do expect a royal road
> to learning. Encouraging them in that does not help them or
> anyone else.
>
>
The main road to learning is probably that it is fun. That is how our
brains work. Learning new names for wellknown things is not that fun. It is
just trivial. (Unless you are learning a new language, of course.)
I would expect Emacs new comers to look for the real interesting things in
Emacs. And those who do that are perhaps those that have most to gain from
Emacs. They might just stop because of the boring trivial things.
[-- Attachment #2: Type: text/html, Size: 1658 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 19:37 ` David Kastrup
2014-01-07 19:50 ` Lennart Borgman
@ 2014-01-08 3:41 ` Richard Stallman
2014-01-08 4:14 ` Bob Bobeck
1 sibling, 1 reply; 47+ messages in thread
From: Richard Stallman @ 2014-01-08 3:41 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Emacs _is_ one of the old great ones. You are trying to make Gandalf
more popular by plucking his nose hairs.
It's not a good analogy. People can like Gandalf as a character
without having to learn lots of incantations.
Learning Emacs is never going to be easy. But we might be able
to change Emacs so that learning it is a little less hard,
and that would be a substantial improvement.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-08 3:41 ` Richard Stallman
@ 2014-01-08 4:14 ` Bob Bobeck
0 siblings, 0 replies; 47+ messages in thread
From: Bob Bobeck @ 2014-01-08 4:14 UTC (permalink / raw
To: rms; +Cc: esr, David Kastrup, emacs-devel
I think it's more like Dumbledwarf. He gets killed in the end. Bwahahhahaha.
On 1/7/14, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Emacs _is_ one of the old great ones. You are trying to make Gandalf
> more popular by plucking his nose hairs.
>
> It's not a good analogy. People can like Gandalf as a character
> without having to learn lots of incantations.
>
> Learning Emacs is never going to be easy. But we might be able
> to change Emacs so that learning it is a little less hard,
> and that would be a substantial improvement.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
> Use Ekiga or an ordinary phone call.
>
>
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 14:10 ` Per Starbäck
@ 2014-01-09 14:48 ` Drew Adams
2014-01-09 15:21 ` Per Starbäck
0 siblings, 1 reply; 47+ messages in thread
From: Drew Adams @ 2014-01-09 14:48 UTC (permalink / raw
To: Per Starbäck, emacs-devel
> users can get the impression that Emacs is not for them because it's weird.
> If they in just the first half hour of using Emacs meet several such things
> they may conclude that working with Emacs will continue to be like this;
> now and then it will turn out that it doesn't work as "expected" and that
> there are new names for everything, etc. Why not use That Other Editor
> that some other people suggested instead?
Why not, indeed? Problem solved.
At ease; false alarm. Circulez ; il n'y a rien a voir.
(And _you_ are not using That Other Editor why? Did you perhaps spend
more than 1/2 hour learning This Old Editor?)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 14:48 ` Emacs terminology (not again!?) [was: Apologia for bzr] Drew Adams
@ 2014-01-09 15:21 ` Per Starbäck
2014-01-09 16:44 ` Drew Adams
0 siblings, 1 reply; 47+ messages in thread
From: Per Starbäck @ 2014-01-09 15:21 UTC (permalink / raw
To: emacs-devel@gnu.org; +Cc: Drew Adams
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
2014/1/9 Drew Adams <drew.adams@oracle.com>
> > users can get the impression that Emacs is not for them because it's
> weird.
> > If they in just the first half hour of using Emacs meet several such
> things
> > they may conclude that working with Emacs will continue to be like this;
> > now and then it will turn out that it doesn't work as "expected" and that
> > there are new names for everything, etc. Why not use That Other Editor
> > that some other people suggested instead?
>
> Why not, indeed? Problem solved.
>
Then you are talking about another problem than I am. Functionality (and
attitudes) that turn away those people is indeed a problem for Emacs. It is
sometimes direct, but often indirect (they don't even try Emacs because a
distro maintainer thought that it shouldn't be installed by default). We
want those users. Especially the part of them that would have become
developers.
(And _you_ are not using That Other Editor why? Did you perhaps spend
> more than 1/2 hour learning This Old Editor?)
>
This seems irrelevant to me. What is your point?
[-- Attachment #2: Type: text/html, Size: 1682 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 15:21 ` Per Starbäck
@ 2014-01-09 16:44 ` Drew Adams
2014-01-09 17:27 ` Per Starbäck
0 siblings, 1 reply; 47+ messages in thread
From: Drew Adams @ 2014-01-09 16:44 UTC (permalink / raw
To: Per Starbäck, emacs-devel
>>> users can get the impression that Emacs is not for them because it's weird.
>>> If they in just the first half hour of using Emacs meet several such things
>>> they may conclude that working with Emacs will continue to be like this;
>>> now and then it will turn out that it doesn't work as "expected" and that
>>> there are new names for everything, etc. Why not use That Other Editor
>>> that some other people suggested instead?
>>
>> Why not, indeed? Problem solved.
>
> Then you are talking about another problem than I am. Functionality (and
> attitudes) that turn away those people is indeed a problem for Emacs.
Are you sure that turning away "those people" is a problem for Emacs?
>> (And _you_ are not using That Other Editor why? Did you perhaps
>> spend more than 1/2 hour learning This Old Editor?)
>
> This seems irrelevant to me. What is your point?
Emacs _is_ a better mousetrap.
http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door
To really appreciate it, some people, if not most, need to give it more
than 1/2 hour, before jumping to the conclusion that it is not worth
their spending more time with it. As Richard put it, "Learning Emacs is
never going to be easy." Or as I said:
Learning Emacs is learning something new and different - it is not
your momma's editor. And it rightfully has its own terminology.
"Those people" who don't feel they need to bother - well, they will
either get it later, by way of others, or they will not. Tant pis.
Emacs losing out because Eclipse or whatever offers more code-refactoring
(or whatever) power, out of the box - that's one thing. Emacs has room
for improvement in lots of areas, no doubt about that.
But Emacs being "weird" because it uses the word "window" differently -
that's another thing. I have never encountered a newbie taking Emacs
for a test drive who could not understand, when told what an Emacs
window is. Have you?
But yes, it might take more than 1/2 hour for Emacs to introduce itself
properly to a user. ("Hello there, I'm GNU Emacs. Who are you?")
This isn't a cocktail party! But even if it were, there are some people
who, if given the opportunity, would give up in 5 minutes after being
introduced to the likes of <INSERT HERE your favorite respected
luminaries and Great Ones>, even if they spoke the same language. Some
people are unfortunately "those people".
Other things being equal, of course we want to make things easy to learn.
Of course we do not want to throw up unnecessary obstacles. Gratuitous
differences in terminology for identical things should be dealt with -
and they generally are.
But (a) that is rare (the Emacs thingies are not really the same), and
(b) even then it is not important to toe the line. Especially if the
things are identical, it is easy to learn new terms for them.
The Emacs UI and doc have been dealing with this for almost 4 decades
now. It does take at least a few minutes and a few examples to get the
notion and behavior of an Emacs "buffer". Weird! Not what you're used
to. Give it a little time. A better mousetrap - you'll see.
That kind of hand-holding encouragement is fine. But there is no reason
to underestimate potential users. Some people will give up without
giving Emacs a chance. So what? Others will not - just as you did not.
Why suppose that potential Emacs users are less patient or curious or
intelligent than we are?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 16:44 ` Drew Adams
@ 2014-01-09 17:27 ` Per Starbäck
2014-01-09 17:42 ` David Kastrup
0 siblings, 1 reply; 47+ messages in thread
From: Per Starbäck @ 2014-01-09 17:27 UTC (permalink / raw
To: emacs-devel@gnu.org; +Cc: Drew Adams
[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]
2014/1/9 Drew Adams <drew.adams@oracle.com>
> > Then you are talking about another problem than I am. Functionality (and
> > attitudes) that turn away those people is indeed a problem for Emacs.
>
> Are you sure that turning away "those people" is a problem for Emacs?
>
>
Yes. Any attitude of "it should be hard to learn because the good people
can learn things that are hard to learn" is just contraproductive.
> >> (And _you_ are not using That Other Editor why? Did you perhaps
> >> spend more than 1/2 hour learning This Old Editor?)
> >
> > This seems irrelevant to me. What is your point?
>
> Emacs _is_ a better mousetrap.
>
> http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door
>
> To really appreciate it, some people, if not most, need to give it more
> than 1/2 hour, before jumping to the conclusion that it is not worth
> their spending more time with it. As Richard put it, "Learning Emacs is
> never going to be easy." Or as I said:
>
> Learning Emacs is learning something new and different - it is not
> your momma's editor. And it rightfully has its own terminology.
>
Those are not comparable quotes at all. Richard wants Emacs to be easier to
learn for beginners, and I doubt he would write something like your momma
quote. Emacs is the text editor for a GNU system. It shouldn't need some
other text editor for "your momma" besides it, but have Emacs be the
program used for any user who need plain text editing. That Gnome had to
create a new text editor to be the default editor for Gnome was a *big*
setback for Emacs.
To really appreciate any text editor takes time.
> "Those people" who don't feel they need to bother - well, they will
> either get it later, by way of others, or they will not. Tant pis.
>
That works only if your goal is this elite Emacs. The "right" users will
find it eventually anyway. Not all people have that idea about Emacs.
> But Emacs being "weird" because it uses the word "window" differently -
> that's another thing. I have never encountered a newbie taking Emacs
> for a test drive who could not understand, when told what an Emacs
> window is. Have you?
>
>
That's rehashing. It's not about understanding. It's about what impression
you make.
>
> Other things being equal, of course we want to make things easy to learn.
> Of course we do not want to throw up unnecessary obstacles. Gratuitous
> differences in terminology for identical things should be dealt with -
> and they generally are.
>
So why do you object when people want to deal with this particular
gratuitous difference in terminology? The proposed window->pane change
doesn't affect other stuff. Yes, an Emacs "buffer" for instance is an Emacs
concept that you have to learn because it's different from what you've used
elsewhere, but that's not part of this at all.
> That kind of hand-holding encouragement is fine. But there is no reason
> to underestimate potential users. Some people will give up without
> giving Emacs a chance. So what? Others will not - just as you did not.
> Why suppose that potential Emacs users are less patient or curious or
> intelligent than we are?
>
My using Emacs is irrelevant. One reason is that I learned (Teco) Emacs in
the 1980s, when expectations on how to learn programs were very different
from now, and with not really any other text editors to choose from anyway.
Another is that the main reason I'm using (GNU) Emacs now is that it's the
editor of the GNU system. If GNU had gone with something else I would
probably have started using that instead, even though that would have been
a much bigger transition than going from one Emacs to another.
[-- Attachment #2: Type: text/html, Size: 5384 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 17:27 ` Per Starbäck
@ 2014-01-09 17:42 ` David Kastrup
2014-01-09 19:11 ` Tom
2014-01-10 14:37 ` Richard Stallman
0 siblings, 2 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-09 17:42 UTC (permalink / raw
To: emacs-devel
Per Starbäck <per@starback.se> writes:
> 2014/1/9 Drew Adams <drew.adams@oracle.com>
>
>> > Then you are talking about another problem than I am. Functionality (and
>> > attitudes) that turn away those people is indeed a problem for Emacs.
>>
>> Are you sure that turning away "those people" is a problem for Emacs?
>>
> Yes. Any attitude of "it should be hard to learn because the good
> people can learn things that are hard to learn" is just
> contraproductive.
It's more like "it's unavoidable to provide difficulties to learning
because it can do a lot, and when a lot is easily accessible, you'll
have stuff getting in your hair accidentally".
Musicians learn their instruments, craftsmen learn their tools.
Unfretted bowed string instruments remain a favorite even though the
possibilities for producing wrong notes or sounds that cannot in good
conscience even be called "tones" are staggering when compared to, say,
a piano. Attempts to cut down on variables the player can get wrong,
like the hurdy gurdy, did not really take off.
A programmer will spend most of his life interacting with an editor and
texts.
> Those are not comparable quotes at all. Richard wants Emacs to be
> easier to learn for beginners, and I doubt he would write something
> like your momma quote.
A carving knife with an exploding handle is not going to be popular.
But you won't be able to sell one with a blunt edge "for safety" either.
Within the variables, one wants to make things as simple as possible but
not simpler.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 17:42 ` David Kastrup
@ 2014-01-09 19:11 ` Tom
2014-01-09 19:38 ` David Kastrup
2014-01-09 22:24 ` Drew Adams
2014-01-10 14:37 ` Richard Stallman
1 sibling, 2 replies; 47+ messages in thread
From: Tom @ 2014-01-09 19:11 UTC (permalink / raw
To: emacs-devel
David Kastrup <dak <at> gnu.org> writes:
>
> It's more like "it's unavoidable to provide difficulties to learning
> because it can do a lot, and when a lot is easily accessible, you'll
> have stuff getting in your hair accidentally".
Arbitrary roadblocks can be removed, though.
For example, yank is not a superior term to paste, so paste could be
used instead. One unnecessary difference less. And it is only one example,
there are others.
Emacs provides enough material to learn without these arbitrary (legacy)
differences, so these should be eliminated where possible.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 19:11 ` Tom
@ 2014-01-09 19:38 ` David Kastrup
2014-01-10 18:10 ` Davis Herring
2014-01-09 22:24 ` Drew Adams
1 sibling, 1 reply; 47+ messages in thread
From: David Kastrup @ 2014-01-09 19:38 UTC (permalink / raw
To: emacs-devel
Tom <adatgyujto@gmail.com> writes:
> David Kastrup <dak <at> gnu.org> writes:
>>
>> It's more like "it's unavoidable to provide difficulties to learning
>> because it can do a lot, and when a lot is easily accessible, you'll
>> have stuff getting in your hair accidentally".
>
> Arbitrary roadblocks can be removed, though.
>
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less.
You mean, unnecessary similarity. This has a C-y keyboard binding, and
vi uses y and Y bindings for yanking as well.
> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.
The problem is that they are not "arbitrary" but deeply ingrained into
the choice of keyboard sequences. And C-x and C-c are pretty much the
most reliably accessible control characters, so they make good sense for
starting multiple keystroke sequences.
What _is_ somewhat annoying in contrast is the positioning of C-b C-n
C-p and C-f. The hjkl sequences of vi or C-s C-x C-e C-d sequences of
WordStar make more sense.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* RE: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 19:11 ` Tom
2014-01-09 19:38 ` David Kastrup
@ 2014-01-09 22:24 ` Drew Adams
1 sibling, 0 replies; 47+ messages in thread
From: Drew Adams @ 2014-01-09 22:24 UTC (permalink / raw
To: Tom, emacs-devel
> Arbitrary roadblocks can be removed, though.
I said as much:
Gratuitous differences in terminology for identical things
are something else. But (a) that is rare (the Emacs thingies
are not really the same), and (b) even then it is not
important to toe the line. Especially if the things are
identical, it is easy to learn new terms for them.
IOW, the truly arbitrary differences are rare and not a problem.
Learning Emacs is hard, but not because of them.
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less. And it is only one
> example, there are others.
>
> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.
To repeat (you might want to read the thread):
Examples of exceptional things that are identical in Emacs,
or nearly so, are "cut" and "paste" operations. And as
others have already said, it is enough to point out the
Emacs terminology and the correspondences (when there are
close correspondences and not just faux amis) - which we
already do, AFAIK.
We already make clear in the menus and doc that "yank" means
something very similar to "paste".
And (to repeat, again) far more importantly: this is NOT a
point of "confusion" for newbies.
Initial ignorance, yes. But the slightest contact with the
Emacs docs or google or a quick Q & A has always been enough to
let newbies know what "yank" means. I have never seen anyone
become "confused" after they were introduced to the term "yank".
This is simply a non-problem. But it gets rehashed here every
so often.
NOT because newbies say they are confused and don't get it.
But only because some well meaning soles here get the bright
idea that this must be confusing to new arrivals and that if
this important obstacle were removed then Emacs would have a
brighter future.
This essentially short-sells newbies, and touches on demagogy.
_You_ learned "yank". Did you stay up at night in turmoil,
trying to grasp its meaning? No. Don't you think that other
newbies are just as bright as you were? Please, think about it.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-07 20:31 ` Drew Adams
2014-01-07 20:42 ` Lennart Borgman
@ 2014-01-10 2:12 ` David Reitter
2014-01-10 19:10 ` Tom
1 sibling, 1 reply; 47+ messages in thread
From: David Reitter @ 2014-01-10 2:12 UTC (permalink / raw
To: Drew Adams; +Cc: Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]
On Jan 7, 2014, at 3:31 PM, Drew Adams <drew.adams@oracle.com> wrote:
> Concrete suggestions about that might well be helpful.
I had some suggestions or questions back in 2005 or thereabouts, when I was less familiar with Emacs,
and I asked questions on this mailing list. Perhaps now the time is better (although I have less time).
Many things are vastly improved from what they were back then - better default key bindings, ELPA, copy&paste with other apps working out of the box, and so on.
At this time, my concrete suggestion I would have is to make semantic, CEDET and etags work out-of-the-box for all major programming paradigms, and make them work without noticeable performance penalty. Standard IDEs like Netbeans, Eclipse or Xcode give me that. Emacs 24 has come a long way, but it's not quite there yet. For instance, I can enable Semantic from the menu, but then I'd try C-M-/ for a completion, next to [win ...] in nsterm.m, and that doesn't give me all the members of the class of "win", in the correct capitalization. In .c files, I get at least some helpful echo area messages, but scrolling gets sluggish. Netbeans doesn't do that. And it just-in-time compiles, marks syntax errors automatically right in the source code, and so on, and so forth.
The second suggestion is better project management, integrated with Semantic. Some ingredients, like Speedbar and Desktop, are there, but they do not provide an integrated experience.
Other people will have other suggestions...
> What you suggest
> is not a bad goal, but the starting point should not be to short-sell
> newbie Emacs users (not suggesting your approach does that; I don't
> know). They are as bright as past newbies, no doubt.
Indeed, that's not what I meant. It's just that even intelligent people prefer to spend their cognitive resources on the actual tasks they are employed to do, or the tasks they intend to do, rather than to learn the tool. We're in a world where software has become obvious to use, or at least very discoverable.
> You
> cannot just pick up Emacs expecting it to do what you are used to,
> without being disappointed or missing the boat.
The idea in Aquamacs is that you can do that, and transition to faster routines as you go along.
It's probably true that the proportion of highly proficient users is smaller, but the overall number of users is greater.
> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search. The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers.
Yes, programming has become very much a copy&paste (sorry, kill&yank) effort. For many programming projects, that is sufficient. You won't get to hack away at Google, Inc., or at Oracle Corp that way, but that's probably OK.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 17:42 ` David Kastrup
2014-01-09 19:11 ` Tom
@ 2014-01-10 14:37 ` Richard Stallman
2014-01-17 23:13 ` Per Starbäck
1 sibling, 1 reply; 47+ messages in thread
From: Richard Stallman @ 2014-01-10 14:37 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Emacs is never going to be as easy to learn as simple
editors, because ease of learning is not its priority.
The priority is effective editing for people willing to learn.
We won't sacrifice that goal for ease of learning.
However, when we can make Emacs easier to learn
at the cost of only _development work_, with no sacrifice in
the principal goal, why not do it?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-09 19:38 ` David Kastrup
@ 2014-01-10 18:10 ` Davis Herring
2014-01-10 18:12 ` David Kastrup
0 siblings, 1 reply; 47+ messages in thread
From: Davis Herring @ 2014-01-10 18:10 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
>> For example, yank is not a superior term to paste, so paste could be
>> used instead. One unnecessary difference less.
>
> You mean, unnecessary similarity. This has a C-y keyboard binding, and
> vi uses y and Y bindings for yanking as well.
Except that "yank" means "copy" in vi, not "paste". (This is the source
of most confusion I see about the word.)
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-10 18:10 ` Davis Herring
@ 2014-01-10 18:12 ` David Kastrup
0 siblings, 0 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-10 18:12 UTC (permalink / raw
To: Davis Herring; +Cc: emacs-devel
Davis Herring <herring@lanl.gov> writes:
>>> For example, yank is not a superior term to paste, so paste could be
>>> used instead. One unnecessary difference less.
>>
>> You mean, unnecessary similarity. This has a C-y keyboard binding, and
>> vi uses y and Y bindings for yanking as well.
>
> Except that "yank" means "copy" in vi, not "paste".
Uh yeah, forgot about that...
> (This is the source of most confusion I see about the word.)
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-10 2:12 ` David Reitter
@ 2014-01-10 19:10 ` Tom
0 siblings, 0 replies; 47+ messages in thread
From: Tom @ 2014-01-10 19:10 UTC (permalink / raw
To: emacs-devel
David Reitter <david.reitter <at> gmail.com> writes:
>
> At this time, my concrete suggestion I would have is to make semantic, CEDET
and etags work out-of-the-box for all major programming paradigms, and make
them work without noticeable performance penalty.
I'd suggest giving some attention to Eclim too. It can do things which
other tools cannot AFAIK. E.g. offering code fixes and stuff. See here:
http://www.skybert.net/emacs/java/
Of course, it requires Eclipse, but it's not necessarily a disadvantage,
because lots of users use Eclipse today and they try emacs beside that.
So it can even be an advantage, because the user can work in eclipse
as usual and at the same time he can work with the same project in
emacs. It makes very easy to try working in emacs, because the user
does not have to create a new environment for developing with emacs,
emacs simply connects to the running eclipse instance.
And Eclim has lots of low hanging fruits, so it can be improved
with little effort. It only needs some attention, because the current
maintainer said he wouldn't implement stuff he didn't use:
http://fredrik.appelberg.me/2013/06/10/maintainer-blues.html
So a polished/improved Eclim would be very useful for newbie users
even if it's not part of core Emacs, because it makes easy to
try working in emacs.
Here's a list of what Eclim is capable of, and only a fraction of
this is implemented by the emacs interface, though it's not hard
to implement them (it involves only calling the relevant operations
and presenting the results to the user):
Eclipse Projects
Create, update, and delete Eclipse projects.
Easily manage Eclipse .classpath files (support for maven and ivy).
Quickly and easily manage settings globally or on a project basis.
Java
Automatic source code validation (w/ visual marking of errors and warnings).
Context sensitive code completion.
Code correction suggestions with option to apply a suggestion.
Class constructor generation.
Java Bean getter and setter generation.
Generation of delegate methods.
Java source and java doc searching capabilities.
Generate stub methods from implemented interfaces or super classes.
Generate stub methods for junit testing.
Quickly clean and sort imports and easily import new classes.
Automatic generation of logging initialization code, upon first usage of a
logger.
Javadoc generation for package, class, field, method, etc.
Java regular expression testing.
Support for Checkstyle.
Validation of log4j xml files.
C/C++
Context sensitive code completion.
Searching.
Source code validation.
Css
Context sensitive code completion.
Source code validation.
Html
Context sensitive code completion.
Automatic validation (w/ visual marking of errors and warnings).
Android
Support for creating android projects
Ant
Ant execution from any file.
Context sensitive code completion when editing build files.
Automatic validation of build files (w/ visual marking of errors and warnings).
Quick access to ant documentation.
Maven
Maven execution from any file.
Maven repository searching and ability to add results to pom file.
JavaScript
File validation using jsl.
Php
Code completion.
Searching.
Source code validation.
Python
Context sensitive code completion.
Find element definition support.
Regular expression testing.
Django functionality.
Validation via python compiler, pyflakes, and pylint.
Ruby
Context sensitive code completion.
Searching.
Source code validation.
Xml / Dtd / Xsd
Automatic validation (w/ visual marking of errors and warnings).
Quickly look up element definition from the current xml file's dtd or xsd.
Context sensitive code completion.
And more...
http://eclim.org/features.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-10 14:37 ` Richard Stallman
@ 2014-01-17 23:13 ` Per Starbäck
2014-01-17 23:38 ` David Kastrup
2014-01-18 8:28 ` Eli Zaretskii
0 siblings, 2 replies; 47+ messages in thread
From: Per Starbäck @ 2014-01-17 23:13 UTC (permalink / raw
To: rms; +Cc: David Kastrup, emacs-devel@gnu.org
Richard wrote:
> Emacs is never going to be as easy to learn as simple
> editors, because ease of learning is not its priority.
> The priority is effective editing for people willing to learn.
> We won't sacrifice that goal for ease of learning.
I find this remark about "simple editors" interesting, not just in
terms of Emacs, but of the
whole GNU system. I have always thought of GNU Emacs as *the* editor
in GNU, that is
the default editor. Do you think a GNU system ideally instead should
have some other
("simple") editor as the default editor? And that using Emacs should
be an active choice for
those who are ready to learn something more powerful? This is news to
me in that case.
I still think Emacs should be *the* editor in GNU, and that it is
perfectly possible to have it
like that without sacrificing the goal of effective editing. New users
that only have used at
most simple text editors don't really need or expect much in my
experience. They type text, move around with scrolling wheel and arrow
keys, and look for anything else in toolbars
and menus. They can certainly do that in Emacs.
(What's the point of them doing this in Emacs instead of in a simple
text editor? Because
some of them will become power users, and then they'll already be in
Emacs when they
start looking for more functionality. It's also a point that they can
be thought of as doing
their stuff in Emacs, because then distribution maintainers are more
likely to steer users
into using Emacs. It's not as if all new users make a choice between a
"simple" and a
"powerful" editor, but most of them will use whatever is the default
one on their system, at
least in the beginning, not knowing about the alternatives, and I
think several GNU/Linux
distributions currently don't install Emacs by default at all.)
> However, when we can make Emacs easier to learn
> at the cost of only _development work_, with no sacrifice in
> the principal goal, why not do it?
I agree. But there is another cost as well, which I think is what we
much more often hear
experienced users object to, namely adjustment costs *for them*.
I like the suggestion of renaming "window" into "pane". It removes one part of
(nowadays) peculiar terminology without big adjustment costs at all
(because of aliases
that would exist).
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-17 23:13 ` Per Starbäck
@ 2014-01-17 23:38 ` David Kastrup
2014-01-18 8:28 ` Eli Zaretskii
1 sibling, 0 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-17 23:38 UTC (permalink / raw
To: Per Starbäck; +Cc: rms, emacs-devel@gnu.org
Per Starbäck <per@starback.se> writes:
> Richard wrote:
>
>> Emacs is never going to be as easy to learn as simple
>> editors, because ease of learning is not its priority.
>> The priority is effective editing for people willing to learn.
>> We won't sacrifice that goal for ease of learning.
>
> I find this remark about "simple editors" interesting, not just in
> terms of Emacs, but of the whole GNU system. I have always thought of
> GNU Emacs as *the* editor in GNU, that is the default editor. Do you
> think a GNU system ideally instead should have some other ("simple")
> editor as the default editor? And that using Emacs should be an active
> choice for those who are ready to learn something more powerful? This
> is news to me in that case.
That's like music instruments that are missing notes to make them
"simpler to learn". It will always come to bite you eventually.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-17 23:13 ` Per Starbäck
2014-01-17 23:38 ` David Kastrup
@ 2014-01-18 8:28 ` Eli Zaretskii
2014-01-18 8:48 ` Lennart Borgman
1 sibling, 1 reply; 47+ messages in thread
From: Eli Zaretskii @ 2014-01-18 8:28 UTC (permalink / raw
To: Per Starbäck; +Cc: dak, rms, emacs-devel
> Date: Sat, 18 Jan 2014 00:13:50 +0100
> From: Per Starbäck <per@starback.se>
> Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>
> Richard wrote:
>
> > Emacs is never going to be as easy to learn as simple
> > editors, because ease of learning is not its priority.
> > The priority is effective editing for people willing to learn.
> > We won't sacrifice that goal for ease of learning.
>
> I find this remark about "simple editors" interesting, not just in
> terms of Emacs, but of the whole GNU system. I have always thought
> of GNU Emacs as *the* editor in GNU, that is the default editor. Do
> you think a GNU system ideally instead should have some other
> ("simple") editor as the default editor?
That's not what Richard was saying, not at all. There could very well
be a "simple" editor that is part of the GNU project (perhaps there is
one already). No one said the GNU project must have only one editor.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 8:28 ` Eli Zaretskii
@ 2014-01-18 8:48 ` Lennart Borgman
2014-01-18 10:02 ` David Kastrup
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-18 8:48 UTC (permalink / raw
To: Eli Zaretskii
Cc: Per Starbäck, Richard M. Stallman, David Kastrup,
Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sat, 18 Jan 2014 00:13:50 +0100
> > From: Per Starbäck <per@starback.se>
> > Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <
> emacs-devel@gnu.org>
> >
> > Richard wrote:
> >
> > > Emacs is never going to be as easy to learn as simple
> > > editors, because ease of learning is not its priority.
> > > The priority is effective editing for people willing to learn.
> > > We won't sacrifice that goal for ease of learning.
> >
> > I find this remark about "simple editors" interesting, not just in
> > terms of Emacs, but of the whole GNU system. I have always thought
> > of GNU Emacs as *the* editor in GNU, that is the default editor. Do
> > you think a GNU system ideally instead should have some other
> > ("simple") editor as the default editor?
>
> That's not what Richard was saying, not at all. There could very well
> be a "simple" editor that is part of the GNU project (perhaps there is
> one already). No one said the GNU project must have only one editor.
>
>
>
But this is of course not really true:
> > Emacs is never going to be as easy to learn as simple
> > editors, because ease of learning is not its priority.
There could be a setup of Emacs that is as easy as any editor to learn. It
is the advanced features that will take time to learn.
I guess that we are really discussing is if there is an advantage of such a
setup. In the light of that there was a whole new editor (gedit) created I
think there could have been a better route. Emacs could probably have
provided everything that gedit gives.
I also guess it would have been less work. And there would have been a
larger community using and working on Emacs.
This does not mean, I think, that the creating of gedit was a bad thing.
There are of course things on the positive side too. Those that created
gedit might speak better about that.
I believe the way forward is being open minded about plus and minus. In the
history and future. Everybody here has the capacity to be that. That is
what lead us to use Emacs, isn't it? ;-)
[-- Attachment #2: Type: text/html, Size: 4205 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 8:48 ` Lennart Borgman
@ 2014-01-18 10:02 ` David Kastrup
2014-01-18 11:03 ` Lennart Borgman
2014-01-18 16:28 ` Óscar Fuentes
2014-01-19 12:10 ` Richard Stallman
2014-01-20 12:22 ` Phillip Lord
2 siblings, 2 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-18 10:02 UTC (permalink / raw
To: emacs-devel
Lennart Borgman <lennart.borgman@gmail.com> writes:
> On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Emacs is never going to be as easy to learn as simple
>> > editors, because ease of learning is not its priority.
>
> There could be a setup of Emacs that is as easy as any editor to
> learn.
That's a red herring. What people are looking for are not editors that
are easy to learn, but editors that can be used without learning
anything at all.
I encounter this situation as an accordion player: the joke in
<URL:http://eu.art.com/products/p24328669009-sa-i7924441/uli-stein-akkordeon-kleiner.htm>,
namely somebody asking for a smaller-size accordion, is not without a
serious background: people imagine that capsizing a piano will make for
a good user interface. It doesn't. Back problems are frequent with
accordion players, and particularly women are often slumped in their
chairs in order to accommodate the vertical dimension of their keyboard.
I play a chromatic button accordion which has buttons rather than piano
keys, and I have 62 notes accessible where a piano accordion has at most
45, and even a small piano accordion with 37 keys has a larger height
than my instrument and its key mechanics take from the immediate
airflow/valve/button interaction facilitating good leggiero play and
bellows control.
If you take a look at nations where accordions are "mainstream" music
instruments, like Finland, France, Russia, you'll find a prevalence of
button instruments. Internationally, it's about evenly split for
accordion soloists, and about 90% piano accordion for accordion
orchestra players (accordion orchestras are collection of accordionists
no other instrumentalists want to play with). The ratio would be even
higher except for orchestras from those accordion nations where piano
accordions are considered outlandish altogether.
If viewed in the grand overall scheme of things, it begs the question if
we are doing Emacs a favor by giving it the piano keyboard more people
think they know how to work with.
Yes, it makes it easier to employ Emacs as a throwaway editor you
occasionally use and forget again.
> I guess that we are really discussing is if there is an advantage of
> such a setup. In the light of that there was a whole new editor
> (gedit) created I think there could have been a better route. Emacs
> could probably have provided everything that gedit gives.
>
> I also guess it would have been less work. And there would have been a
> larger community using and working on Emacs.
In countries where the piano accordion is prevalent, accordions are more
often associated with music styles, groups, and shows that "serious"
musicians consider a laughing stock. That definitely impacts the influx
of new players. And in particular, new virtuosi.
The future of Emacs depends on people with an attention span and
perseverence sufficient for extending it. Those are the people who are
most likely to be annoyed at the inconsistency of concepts and
operations of things like the full CUA mode (the one which uses
heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
sense).
We should not try to be too clever about looking simple: we will only
fool those people who don't actually count towards the well-being of
Emacs. So any changes should be done while keeping the coherence of the
result closely in check.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 10:02 ` David Kastrup
@ 2014-01-18 11:03 ` Lennart Borgman
2014-01-18 11:32 ` David Kastrup
2014-01-18 16:28 ` Óscar Fuentes
1 sibling, 1 reply; 47+ messages in thread
From: Lennart Borgman @ 2014-01-18 11:03 UTC (permalink / raw
To: David Kastrup; +Cc: Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> > On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > Emacs is never going to be as easy to learn as simple
> >> > editors, because ease of learning is not its priority.
> >
> > There could be a setup of Emacs that is as easy as any editor to
> > learn.
>
> That's a red herring. What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.
>
Do you believe you will convince me with this, or? ;-)
Facts are much better if we do not agree. If we agreed this might have been
better, more fun, of course... ;-)
>
>
> I guess that we are really discussing is if there is an advantage of
> > such a setup. In the light of that there was a whole new editor
> > (gedit) created I think there could have been a better route. Emacs
> > could probably have provided everything that gedit gives.
> >
> > I also guess it would have been less work. And there would have been a
> > larger community using and working on Emacs.
>
> The future of Emacs depends on people with an attention span and
> perseverence sufficient for extending it. Those are the people who are
> most likely to be annoyed at the inconsistency of concepts and
> operations of things like the full CUA mode (the one which uses
> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
> sense).
>
> Are you really sure you want to look down upon those that do not agree? ;-)
[-- Attachment #2: Type: text/html, Size: 3286 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 11:03 ` Lennart Borgman
@ 2014-01-18 11:32 ` David Kastrup
2014-01-18 13:13 ` Sivaram Neelakantan
0 siblings, 1 reply; 47+ messages in thread
From: David Kastrup @ 2014-01-18 11:32 UTC (permalink / raw
To: Lennart Borgman; +Cc: Emacs-Devel devel
Lennart Borgman <lennart.borgman@gmail.com> writes:
> On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:
>
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>> > I guess that we are really discussing is if there is an advantage of
>> > such a setup. In the light of that there was a whole new editor
>> > (gedit) created I think there could have been a better route. Emacs
>> > could probably have provided everything that gedit gives.
>> >
>> > I also guess it would have been less work. And there would have been a
>> > larger community using and working on Emacs.
>>
>> The future of Emacs depends on people with an attention span and
>> perseverence sufficient for extending it. Those are the people who are
>> most likely to be annoyed at the inconsistency of concepts and
>> operations of things like the full CUA mode (the one which uses
>> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
>> sense).
>
> Are you really sure you want to look down upon those that do not
> agree? ;-)
It's not a question on looking up or down. Let me quote from the CUA
mode section in the Emacs manual:
The command ‘M-x cua-mode’ sets up key bindings that are compatible with
the Common User Access (CUA) system used in many other applications.
When CUA mode is enabled, the keys ‘C-x’, ‘C-c’, ‘C-v’, and ‘C-z’
invoke commands that cut (kill), copy, paste (yank), and undo
respectively. The ‘C-x’ and ‘C-c’ keys perform cut and copy only if the
region is active. Otherwise, they still act as prefix keys, so that
standard Emacs commands like ‘C-x C-c’ still work. Note that this means
the variable ‘mark-even-if-inactive’ has no effect for ‘C-x’ and ‘C-c’
(*note Using Region::).
To enter an Emacs command like ‘C-x C-f’ while the mark is active,
use one of the following methods: either hold ‘Shift’ together with the
prefix key, e.g., ‘S-C-x C-f’, or quickly type the prefix key twice,
e.g., ‘C-x C-x C-f’.
Now this is touted as a feature to make things _simple_ for people. In
reality, _competent_ use of it requires _lots_ of learning and
surprises. If I enable CUA mode and type C-h k C-x C-c, I read
C-x C-c runs the command save-buffers-kill-terminal, which is an
interactive compiled Lisp function in `files.el'.
It is bound to C-x C-c, <menu-bar> <file> <exit-emacs>.
(save-buffers-kill-terminal &optional ARG)
Offer to save each buffer, then kill the current connection.
If the current frame has no client, kill Emacs itself.
With prefix ARG, silently save all file-visiting buffers, then kill.
If emacsclient was started with a list of filenames to edit, then
only these files will be asked to be saved.
[back]
But if there is an active region, C-h k C-x prints
C-x runs the command cua--prefix-override-handler, which is an
interactive compiled Lisp function in `cua-base.el'.
It is bound to C-c, C-x.
(cua--prefix-override-handler ARG)
Start timer waiting for prefix key to be followed by another key.
Repeating prefix key when region is active works as a single prefix key.
[back]
This kind of mode dependency is what Emacs proponents in the editor wars
tend to describe as a disadvantage of vi.
This kind of "do the expected thing" setup may delay the time until
cursory Emacs users will hit a wall of learning. But when they do, the
wall is higher.
This puts a larger complexity gap between "simple users" and "power
users or programmers" who actually can work their tool with confidence.
I don't see that making Emacs fit the Gedit task space would have
yielded a result where Gedmacs users would have grown into active
participants of the Emacs universe.
In the long run, we need to make sure that Emacs remains comprehensible
to Emacs users. That does not preclude changing keybindings and
concepts, but getting multiple concurrent warring keybindings and
concepts sorted by various heuristics is not the way to simplicity.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 11:32 ` David Kastrup
@ 2014-01-18 13:13 ` Sivaram Neelakantan
2014-01-18 17:22 ` Tom
0 siblings, 1 reply; 47+ messages in thread
From: Sivaram Neelakantan @ 2014-01-18 13:13 UTC (permalink / raw
To: emacs-devel
On Sat, Jan 18 2014,David Kastrup wrote:
[snipped 92 lines]
> In the long run, we need to make sure that Emacs remains comprehensible
> to Emacs users. That does not preclude changing keybindings and
> concepts, but getting multiple concurrent warring keybindings and
> concepts sorted by various heuristics is not the way to simplicity.
No offence to the CUA/EVIL developers but don't these 2 modes get in
the way of Emacs mastery as David says. I can understand someone
asking for the vi . (dot command) functionality equivalent in Emacs
but why humour them with modes that are at cross purposes to Emacs
proficiency?
Here, simplicity begets simple users(with no offence to their
intelligence, just Emacs mastery)
sivaram
--
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 10:02 ` David Kastrup
2014-01-18 11:03 ` Lennart Borgman
@ 2014-01-18 16:28 ` Óscar Fuentes
2014-01-18 17:55 ` David Kastrup
1 sibling, 1 reply; 47+ messages in thread
From: Óscar Fuentes @ 2014-01-18 16:28 UTC (permalink / raw
To: emacs-devel
David Kastrup <dak@gnu.org> writes:
> That's a red herring. What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.
People are looking for editors that work similar enough to those that
they already know.
For most people, the *promise* of improved efficiency is not credible
enough to invest the required time to learn Emacs.
[snip]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
@ 2014-01-18 16:38 grischka
2014-01-18 17:26 ` David Kastrup
0 siblings, 1 reply; 47+ messages in thread
From: grischka @ 2014-01-18 16:38 UTC (permalink / raw
To: dak; +Cc: emacs-devel
David Kastrup wrote:
> If viewed in the grand overall scheme of things, it begs the question if
> we are doing Emacs a favor by giving it the piano keyboard more people
> think they know how to work with.
I don't think the piano keyboard is the problem. It is more the
heap of wires and buttons behind it that may look to you like an
accordion but really is a 1960s Moog vacuum tube synthesizer.
--- grischka
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 13:13 ` Sivaram Neelakantan
@ 2014-01-18 17:22 ` Tom
0 siblings, 0 replies; 47+ messages in thread
From: Tom @ 2014-01-18 17:22 UTC (permalink / raw
To: emacs-devel
Sivaram Neelakantan <nsivaram.net <at> gmail.com> writes:
>
> No offence to the CUA/EVIL developers but don't these 2 modes get in
> the way of Emacs mastery as David says. I can understand someone
> asking for the vi . (dot command) functionality equivalent in Emacs
> but why humour them with modes that are at cross purposes to Emacs
> proficiency?
Emacs mastery is not about using the default keys, it's about
understanding how you can transform Emacs, so it adapts to you,
not the other way around.
I often read from beginners in forums that they think the
keybindings give emacs its power, though the real power is
the lisp environment which allows you to create your own
personal working environment including completely revamping
them and using vi bindings if you want.
So Emacs proficiency has nothing to do with the keys. They
are only the legacy defaults which can be changed as any other
custom aspects of emacs.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 16:38 Emacs terminology (not again!?) [was: Apologia for bzr] grischka
@ 2014-01-18 17:26 ` David Kastrup
0 siblings, 0 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-18 17:26 UTC (permalink / raw
To: grischka; +Cc: emacs-devel
grischka <grishka@gmx.de> writes:
> David Kastrup wrote:
>> If viewed in the grand overall scheme of things, it begs the question if
>> we are doing Emacs a favor by giving it the piano keyboard more people
>> think they know how to work with.
>
> I don't think the piano keyboard is the problem. It is more the
> heap of wires and buttons behind it that may look to you like an
> accordion but really is a 1960s Moog vacuum tube synthesizer.
More like the 1950s. Those things were called "Electronium" and part of
Hohner's master plan to organize the accordionists nobody wanted to play
with into "accordion orchestras".
<URL:https://www.youtube.com/watch?v=eml7J7zi4gA>
The real chutzpah here is claiming "bellows-controlled volume". Those
things did not actually use the (operative) bellows as much for volume
control but for cooling: the simple LC oscillators tended to have quite
a bit of temperature drift. There was a hinge-and-spring mechanism
basically turning the whole instrument into one clumsy volume pedal: the
volume was solely determined by how much you pulled the instrument
apart.
<URL:http://www.vintageaudioberlin.de/vabmenue1/vabmenue3.htm>
Of course, this was decades before Emacs. While the concept has been
dragged through several transistorized and later digital successors, the
popularity has sharply declined and nowadays one sees this thing
mentioned much more often in accordion orchestra scores (its sole
habitat) than one actually sees it in operation.
I digress. Seriously.
At any rate, at that time Hohner was reasonably successful promoting CUA
("could utilize accordions") for a wide spectrum of music genres.
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 16:28 ` Óscar Fuentes
@ 2014-01-18 17:55 ` David Kastrup
0 siblings, 0 replies; 47+ messages in thread
From: David Kastrup @ 2014-01-18 17:55 UTC (permalink / raw
To: emacs-devel
Óscar Fuentes <ofv@wanadoo.es> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> That's a red herring. What people are looking for are not editors that
>> are easy to learn, but editors that can be used without learning
>> anything at all.
>
> People are looking for editors that work similar enough to those that
> they already know.
>
> For most people, the *promise* of improved efficiency is not credible
> enough to invest the required time to learn Emacs.
I'm not convinced that this should overly influence our priorities.
It's like trying to make a piano appealing to iPod users. Both are used
for producing music.
What _should_ be making us think about our priorities is when we lose
the input of heavy Emacs users like RMS, Ben Wing, Nix, to Repetitive
Strain Injury, and it appears like users of other editors are not
affected to a similar degree.
No idea about the actual numbers, though. If they turned out to be more
than just anecdotal, that would at least provide an incentive for
long-term replanning of the default keybindings to be offered.
To me, that would carry more weight than "everybody else does x".
--
David Kastrup
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 8:48 ` Lennart Borgman
2014-01-18 10:02 ` David Kastrup
@ 2014-01-19 12:10 ` Richard Stallman
2014-01-19 12:21 ` Lennart Borgman
2014-01-20 12:22 ` Phillip Lord
2 siblings, 1 reply; 47+ messages in thread
From: Richard Stallman @ 2014-01-19 12:10 UTC (permalink / raw
To: Lennart Borgman; +Cc: eliz, per, dak, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
There could be a setup of Emacs that is as easy as any editor to learn. It
is the advanced features that will take time to learn.
I guess that we are really discussing is if there is an advantage of such a
setup.
We could make an incompatible "simple" interface for Emacs and make it
easy to learn. It could look just like gedit, perhaps.
It might be better, overall, if gedit were implemented as such an
interface to Emacs. I am not sure it would have been less work, though.
However, if you change it that much, it won't give people an easy pathway
to using Emacs. Its commands would be all different.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-19 12:10 ` Richard Stallman
@ 2014-01-19 12:21 ` Lennart Borgman
0 siblings, 0 replies; 47+ messages in thread
From: Lennart Borgman @ 2014-01-19 12:21 UTC (permalink / raw
To: Richard M. Stallman
Cc: Eli Zaretskii, Per Starbäck, David Kastrup,
Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
On Sun, Jan 19, 2014 at 1:10 PM, Richard Stallman <rms@gnu.org> wrote:
>
> We could make an incompatible "simple" interface for Emacs and make it
> easy to learn. It could look just like gedit, perhaps.
>
> It might be better, overall, if gedit were implemented as such an
> interface to Emacs. I am not sure it would have been less work, though.
>
Perhaps it does not matter if it would have been less work in the
beginning. Perhaps the long term outcome matters more.
>
> However, if you change it that much, it won't give people an easy pathway
> to using Emacs. Its commands would be all different.
>
> I see no reason the commands would be different. Not at the beginners
level.
[-- Attachment #2: Type: text/html, Size: 1436 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-18 8:48 ` Lennart Borgman
2014-01-18 10:02 ` David Kastrup
2014-01-19 12:10 ` Richard Stallman
@ 2014-01-20 12:22 ` Phillip Lord
2014-01-20 15:24 ` Eli Zaretskii
2 siblings, 1 reply; 47+ messages in thread
From: Phillip Lord @ 2014-01-20 12:22 UTC (permalink / raw
To: Emacs-Devel devel
Lennart Borgman <lennart.borgman@gmail.com> writes:
>> > Emacs is never going to be as easy to learn as simple
>> > editors, because ease of learning is not its priority.
>
> There could be a setup of Emacs that is as easy as any editor to learn. It
> is the advanced features that will take time to learn.
For what it is worth, I think Emacs could do with some considerable
improvement on the "self-documenting" front. A student of mine recently
asked about tutorials for Emacs. Of course, I said, it's got one
built-in, to which the response was that it was rubbish.
So I went and looked at it for the first time in many years. I think he
has a point. As the warning notice that you get if you change things says:
"The main purpose of the Emacs tutorial is to teach you
the most important standard Emacs commands (key bindings)."
Are key bindings the main thing we want to teach new users?
Worse the first 200 lines are all about how to move the cursor; I mean,
most new users are just going to use the cursor keys, or a mouse. It's
what I do, even after years of using Emacs with a few exceptions
(Ctrl-A, E and M-<,> if you are interested).
It isn't till line 199 that you get something powerful (repeat commands)
rather than painful. Then, we move onto Ctrl-G (line 236) which is what
happens when it breaks. And line 274 get us to Windows. And line 470
before we find out how to open a file.
There are also 4 "If you are on a windowing system" statements: lets be
honest, any new user is going to be on a windowing system. People
starting to use computers today are likely to be unaware that it is
possible to not be on a windowing system.
Other things that seem to be missing, are links to the rest of the
world. Why no links to web pages, or videos? Or indeed, in-line images.
Perhaps, users would be less confused by "windows", "buffers" and so on,
if they hadn't got bored long before the point where these are
explained?
If there is interest in incorporating it, I'd be willing to rewrite it.
Phil
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Emacs terminology (not again!?) [was: Apologia for bzr]
2014-01-20 12:22 ` Phillip Lord
@ 2014-01-20 15:24 ` Eli Zaretskii
0 siblings, 0 replies; 47+ messages in thread
From: Eli Zaretskii @ 2014-01-20 15:24 UTC (permalink / raw
To: Phillip Lord; +Cc: emacs-devel
> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Date: Mon, 20 Jan 2014 12:22:45 +0000
>
> For what it is worth, I think Emacs could do with some considerable
> improvement on the "self-documenting" front. A student of mine recently
> asked about tutorials for Emacs. Of course, I said, it's got one
> built-in, to which the response was that it was rubbish.
>
> So I went and looked at it for the first time in many years. I think he
> has a point.
Indeed. Volunteers are welcome to work on this.
> Worse the first 200 lines are all about how to move the cursor;
But let's be fair: the tutorial starts by saying that arrow keys and
PgUp/PgDn are also supported.
> If there is interest in incorporating it, I'd be willing to rewrite it.
Please do, and thanks in advance.
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2014-01-20 15:24 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-18 16:38 Emacs terminology (not again!?) [was: Apologia for bzr] grischka
2014-01-18 17:26 ` David Kastrup
-- strict thread matches above, loose matches on Subject: below --
2014-01-03 15:21 Apologia for bzr Toby Cubitt
2014-01-04 7:59 ` Richard Stallman
2014-01-04 8:28 ` Eric S. Raymond
2014-01-05 20:20 ` Richard Stallman
2014-01-05 20:41 ` Lennart Borgman
2014-01-06 14:00 ` Richard Stallman
2014-01-06 14:29 ` Lennart Borgman
2014-01-06 20:27 ` Richard Stallman
2014-01-07 0:12 ` Stefan Monnier
2014-01-07 6:21 ` Lars Magne Ingebrigtsen
2014-01-07 7:30 ` Emacs terminology (not again!?) [was: Apologia for bzr] Drew Adams
2014-01-07 10:30 ` Lennart Borgman
2014-01-07 18:05 ` Joel Mccracken
2014-01-07 19:06 ` Drew Adams
2014-01-07 19:17 ` Lennart Borgman
2014-01-07 19:56 ` David Reitter
2014-01-07 20:31 ` Drew Adams
2014-01-07 20:42 ` Lennart Borgman
2014-01-10 2:12 ` David Reitter
2014-01-10 19:10 ` Tom
2014-01-07 19:37 ` David Kastrup
2014-01-07 19:50 ` Lennart Borgman
2014-01-08 3:41 ` Richard Stallman
2014-01-08 4:14 ` Bob Bobeck
2014-01-07 11:13 ` Stephen J. Turnbull
2014-01-07 11:27 ` Lennart Borgman
2014-01-07 12:13 ` Yuri Khan
2014-01-07 14:07 ` Stephen J. Turnbull
2014-01-07 14:16 ` Lennart Borgman
2014-01-07 10:30 ` Apologia for bzr Jose E. Marchesi
2014-01-09 14:10 ` Per Starbäck
2014-01-09 14:48 ` Emacs terminology (not again!?) [was: Apologia for bzr] Drew Adams
2014-01-09 15:21 ` Per Starbäck
2014-01-09 16:44 ` Drew Adams
2014-01-09 17:27 ` Per Starbäck
2014-01-09 17:42 ` David Kastrup
2014-01-09 19:11 ` Tom
2014-01-09 19:38 ` David Kastrup
2014-01-10 18:10 ` Davis Herring
2014-01-10 18:12 ` David Kastrup
2014-01-09 22:24 ` Drew Adams
2014-01-10 14:37 ` Richard Stallman
2014-01-17 23:13 ` Per Starbäck
2014-01-17 23:38 ` David Kastrup
2014-01-18 8:28 ` Eli Zaretskii
2014-01-18 8:48 ` Lennart Borgman
2014-01-18 10:02 ` David Kastrup
2014-01-18 11:03 ` Lennart Borgman
2014-01-18 11:32 ` David Kastrup
2014-01-18 13:13 ` Sivaram Neelakantan
2014-01-18 17:22 ` Tom
2014-01-18 16:28 ` Óscar Fuentes
2014-01-18 17:55 ` David Kastrup
2014-01-19 12:10 ` Richard Stallman
2014-01-19 12:21 ` Lennart Borgman
2014-01-20 12:22 ` Phillip Lord
2014-01-20 15:24 ` Eli Zaretskii
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.