[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Emacs learning curve
RE: Emacs learning curve
Mon, 2 Aug 2010 07:16:49 -0700
> >> Is there a compelling reason to still use yank/kill,
> instead of copy/cut/paste?
> > From the Emacs manual:
> Maybe we should make a concerted effort to change the terminology.
> If someone could go through the manual and docstrings to replace
> yank=>paste (and kill => cut|copy), and also find new names for
> variables, functions, and commands (which will need aliases
> so both the new and old names work), that would be a good start.
> I'd be happy to review such a patch.
Is it a joke?
That would be misguided indeed.
It is better to have different names from the common, whether the Emacs name is
"kill" or "froobarb". Emacs kill is not the same as cut, etc. but it is
sufficiently similar that using the same name will cause confusion and
frustration. Using the names that some users are used to will lead to "bug"
reports because the Emacs behavior is different (superior) to what they expect
by the common name.
We already have Cut, Copy, and Paste in the menus, and we state clearly in the
docs what the similarities and differences are (and that's important). That is
good and proper. It would be misleading, incorrect, and troublesome (especially
to the newbies who will suffer the confusion) to simply change the Emacs names.
Unless you prefer (a) reams of dialog and bug discussions about how Emacs's
"cut" is broken because it is different from the "standard" cut to the current
(rare) (b) complaints that it's hard to find out how to "cut" text in Emacs
because the command name isn't "cut".
Get some perspective, please. How many former newbies have complained that the
command names got in their way? How many? There are plenty on this list - take
The complaints I've seen about the terminology have been from Emacs users (not
newbies) who hope to win more converts to Emacs. Or the occasional complaint
from a newbie who could not find "cut" in the manual because s?he didn't really
look well or look there at all (yes, it's there, including in the index).
You are trying to solve a non-problem, and your solution will itself lead to
> >> Why do we call the cursor the point?
> > Because point is not the cursor. The cursor only shows the position
> > of point in the visible windows (and on character terminals, only in
> > the single selected window). We still need a term for the ``current
> > position in the buffer''.
> I'm not sure that's a good reason: most other applications
> don't bother
> with this distinction, they just call both concepts "cursor" and then
> rely on context to disambiguate. So here as well, I'd be willing to
> entertain the idea of changing terminology if someone were to send
> a patch for it.
So now you will need to make clear when you mean the cursor as the visible thing
that is on a character (display artifact) and when you mean the position before
that character. Which character is the cursor on at eob and bob?
What problem are you trying to solve? This is like some first-year biology
student wanting to eliminate the jargon s?he encounters because s?he doesn't yet
understand that it serves a purpose: it is for making just such distinctions as
s?he does not yet see. _You_, however, should know better.
> >> These relics of old terminology should be updated to the
> accepted modern
> >> variants to make the documentation is more accessible for
> emacs newbies.
> > And then they will be queuing up to start using Emacs, no doubt.
> The idea (for me anyway) is not to lure new users (I have given up the
> hope to understand what they need/want a lot time ago), but
> just to make Emacs better.
You're looking in the wrong place to start making Emacs better.
There's a long list of bugs..., many with proposed solutions.
> And following standards (be they protocols, libraries,
> terminology, behavior) is generally a good thing. So the only reason
> not to follow standards is when we have a better story. In
> the case of yank/paste and point/cursor, I don't think our story
> is that much better: it's more a historical accident.
It is an accident that Emacs chose "kill" rather than "cut". It is not an
accident that these are two different behaviors even if there are similarities.
> Changing such "fundamental" things might not be terribly easy
> given the fact that Emacs's names have real effects on behavior
> (since users refer to them in their .emacs, you can call them
> via M-x, etc...) but that doesn't mean that they're features
> of which we need to be proud (not that we should be ashamed
> of it, either of course: it's nice to remember
> that had those things before they became standard).
Details, please. Mumble mumble - which features?
Emacs did not have its kill before cutting existed elsewhere (whether or not it
was called "cut" back then). And Emacs's kill is different from cut.
RE: Emacs learning curve,
Drew Adams <=
Re: Emacs learning curve, Eli Zaretskii, 2010/08/02
Re: Emacs learning curve, Tom, 2010/08/02