The Modernization of Emacs
Xah Lee
The Modernization of Emacs, Xah Lee, 2006-04 at
http://xahlee.org/emacs/modernization.html
]
The Modernization of Emacs
----------------------------------------
THE PROBLEM
Emacs is a great editor. It is perhaps the most powerful and most
versatile text editor. And, besides text editing, it also serves as a
email application, newsgroup application, ftp application, irc
application, web browser, shell interface, file management
application, programable calculator, calendar and personal info
management application, lisp language system, among other things.
These seemingly wild functionalities are employed in production daily
by a significant number of programers around the world. Some calls
emacs as a Operating System as a joke. (Technically it does not
qualify because a OS implies management of hardware.).
If emacs is such a great and powerful text editor why almost nobody
knows about it? Vast majority of people who need to write will be more
than happy to use editors other than emacs. Ask a Microsoft Windows
user. She'll be more than happy to use Microsoft Word↗. If he doesn't
have MS Word, he'll use NotePad↗ or WordPad↗. If he is a programer,
most will be more than happy to use any of other graphical editors on
the Windows platform or any of the Integrated development
environment↗. Same is true on other operating systems, and new editors
spring up here and there even though they don't have as much power or
flexibility as emacs. For example, there are NEdit, JEdit, Eclipse,
Xcode↗ , or the various associated with languages or third party
language software, such as Visual Basic or Borland C++.
Many reasons can be made out of this. For example, emacs is not
bundled on popular operating systems such as Windows or Mac, which are
used by some 99% of computer users worldwide. Windows and Mac both
have simple text editors bundled that will satisfy majority of
computer users, which are non-professional computer users. (NotePad
and WordPad on Windows, TextEdit↗ on Mac) For the few professional
computer users, a majority will need a easy to use, yet powerful
editor that also does styled text, formatting, and sundry light
publishing needs such as table layout, simple line graphics drawing,
embedded images, math formulas. They will choose and adopt Microsoft
Word for their needs. The tiny percentage that might be interested in
emacs, are programers. Even among professional programers, a majority
shy away from emacs.
A major difficulty among programers who do not use or like emacs, is
that emacs's user interface is rather esoteric, involving arcane
terminologies and keystrokes. This is in sharp contrast to the
thousands of software applications used today, where their User
Interface are similar and familiar to today's computer users.
----------------------------------------
THE COMMON USER INTERFACE
The following is a excerpt from the Wikipedia article on Common User
Access↗:
CUA was a detailed specification and set strict rules about how
applications should look and function. Its aim was in part to bring
about harmony between MS-DOS applications, which until then had
implemented totally different user interfaces.
Examples:
* In WordPerfect, the command to open a file was [F7], [3].
* In Lotus 1-2-3, a file was opened with [/] (to open the menus),
[W] (for Workspace), [R] (for Retrieve).
* In Microsoft Word, a file was opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load).
* In WordStar, it was [Ctrl]+[K]+[O].
* In Emacs, a file was opened with [Ctrl]+[x] followed by [Ctrl]+
[f] (for find-file).
Some programs used [Esc] to cancel an action, some used it to complete
one; WordPerfect used it to repeat a character. Some programs used
[End] to go to the end of a line, some used it to complete filling in
a form. [F1] was often help but in WordPerfect that was [F3]. [Ins]
sometimes toggled between overtype and inserting characters, but some
programs used it for “paste”.
Thus, every program had to be learned individually and its complete
user interface memorized. It was a sign of expertise to have learned
the UIs of dozens of applications, since a novice user facing a new
program would find their existing knowledge of a similar application
absolutely no use whatsoever.
----------------------------------------
SIMPLE CHANGES
In the following, i describe some critical changes that are also very
easy to fix in emacs. If emacs officially adopt these changes, i think
it will make a lot people, at least programers, like emacs and choose
emacs as their text editor.
* Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
v as to be the same with all modern applications.
* Change the undo behavior so that there is a Undo and Redo, as
the same with all modern applications.
* Get rid of the *scratch* buffer.
* Change the terminology of “kill” to “cut”, and “yank” to
“paste”.
* Change the terminology of Meta key to Alt.
* Make longlines-mode the default editor behavior for any file.
Things emacs should do now, even though it eventually will do.
* When opening a HTML document, automatically provide highlighting
of HTML, CSS, and Javascript codes. Similarly for other multi-language
files such as PHP, JSP, et al. This behavior must be automatic without
requiring user to customize emacs.
Possible Documentation Change Proposals
* Reduce the use of the word “buffer” in the emacs documentation.
Call it “opened file” or “unsaved document”.
* Switch the terminology of Window and Frame so it is more
standard. That is, Emacs's “Window” should be called Panes or Frames.
While Emacs's “Frame” should be termed Window.
* Change the terminology of keybinding to “keyboard shortcut” in
emacs documentation. Use the term keybinding or binding only in a
technical context, such as in elisp documentation.
Thomas F. Burdick
distribution that, which not there yet, is at least half way between
"classic" Emacs and a modern Mac UI. You sound ridiculous, like if
you were complaining about Windows not being really graphical, based
on experience with Windows-386 in the era when 95 was already around.
On Jun 17, 5:13 pm, Xah Lee <x...@xahlee.org> wrote:
> [this post is a excerpt from
> The Modernization of Emacs, Xah Lee, 2006-04 athttp://xahlee.org/emacs/modernization.html
Twisted
[snip]
Whoa. Xah posted something I agree with wholeheartedly. Imagine that.
Philipp Leitner
who will not use emacs for their day-to-day work simply because they
have tools that suit them better for the work they have to do (Eclipse
for me, as an example)?
Except from that: I personally don't feel that your rantings are
interesting enough to qualify for a 4 groups X-post ... this sort of
article goes well into a blog, but not so much on programmers
newsgroups (which are used for Q&A imho).
George Sakkis
You must be new here. Xah is a well-known self-important troll,
crossposting his mostly off-topic and/or controversial ramblings and
showing off his ignorance in a provocative condescending manner. Don't
waste resources by replying, he rarely follows up anyway.
cmr....@gmail.com
> In the following, i describe some critical changes that are also very
> easy to fix in emacs. If emacs officially adopt these changes, i think
> it will make a lot people, at least programers, like emacs and choose
> emacs as their text editor.
>
> * Change the keyboard shortcut of Copy & Paste to ctrl-c and ctrl-
> v as to be the same with all modern applications.
>
> * Get rid of the *scratch* buffer.
>
I agree that it should be off by default. I hope that only a minority
of emacs users are emacs developers ;-)
> * Change the terminology of "kill" to "cut", and "yank" to
> "paste".
>
In my emacs 21 in menu it says just that.
> * Change the terminology of Meta key to Alt.
>
I guess emacs is not for PC only...
> * Make longlines-mode the default editor behavior for any file.
>
This is doubtful, but I agree that all modes (LaTeX etc) should at
least work correctly with longlines mode.
> * When opening a HTML document, automatically provide highlighting
> of HTML, CSS, and Javascript codes. Similarly for other multi-language
> files such as PHP, JSP, et al. This behavior must be automatic without
> requiring user to customize emacs.
>
For me it opens R files with proper highlighting out-of-the-box -_-;
> * Reduce the use of the word "buffer" in the emacs documentation.
> Call it "opened file" or "unsaved document".
>
As far as I understand the concept of buffer is much much wider than
of "unsaved document" or "file". Should we call dired buffer as
"unsaved document"?
> Xah
> x...@xahlee.org
> http://xahlee.org/
alexan...@gmail.com
> > * Reduce the use of the word "buffer" in the emacs documentation.
> > Call it "opened file" or "unsaved document".
>
> As far as I understand the concept of buffer is much much wider than
> of "unsaved document" or "file". Should we call dired buffer as
> "unsaved document"?
>
It is much wider, which is why it was used in the first place.
Considering most of Xah's article, I think an animated paperclip
(maybe in ASCII art) should be the top priority for emacs developers.
This would be an important step in modernizing emacs.
Leaving this aside, I'm also taking a wild guess that some *nices (not
just Linux distros, but also *BSD, Solaris etc.) could well provide a
binary package of emacs compiled with its GTK UI, besides those
they're already providing (nox and the ugly one for X). It's a fair
assumption to consider that not anyone has GTK, but it's common enough
to provide an alternative to that stumpy Xlib-based (I think :-\) UI
that's default in just about every binary package around. It's not
just that it looks ugly, it's also somewhat awkward at times.
Joel J. Adamson
> ----------------------------------------
> SIMPLE CHANGES
>
> In the following, i describe some critical changes that are also very
> easy to fix in emacs. If emacs officially adopt these changes, i think
> it will make a lot people, at least programers, like emacs and choose
> emacs as their text editor.
The problem with this line of thinking is that it aims to make Emacs
appeal to people -- I think it is rather the other way around.
Certain people appeal to Emacs: certain kinds of people like Emacs
and the way it is set up, and they change it to suit their needs.
Among your changes, I found none that made sense to me, a person who
used Unix before Windows became widely used. For people like me, who
always preferred Unix, changes like changing "buffer" to "opened file"
seem inefficient and unnecessary.
Sorry -- this totally falls flat. It won't make Emacs more widely
used. The only thing that will make Emacs more widely used is making
people aware of it; as soon as I became aware of Emacs (from reading
Wikipedia, ironically), I began using it and I knew I was stuck with
it. It's not even important for the survival of Emacs that it be more
widely used -- it was never important in the last thirty years of its
history, why should it be important now that Microsoft Word is so
widely used?
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
Robin Becker
> people aware of it; as soon as I became aware of Emacs (from reading
> Wikipedia, ironically), I began using it and I knew I was stuck with
> it. It's not even important for the survival of Emacs that it be more
many others get stuck with a preferred editor/system/language; I guess it takes
some real enthusiasm to switch from vi to emacs or jedit or brief. Years ago
they switched my escape key from top right to top left (dec keyboards were
weird); the body is very hard to retrain. I don't know what those synapse
memories are called, bit they go very deep.
--
Robin Becker
Hal Vaughan
> Xah Lee <x...@xahlee.org> writes:
>
>> ----------------------------------------
>> SIMPLE CHANGES
>>
>> In the following, i describe some critical changes that are also very
>> easy to fix in emacs. If emacs officially adopt these changes, i think
>> it will make a lot people, at least programers, like emacs and choose
>> emacs as their text editor.
>
> The problem with this line of thinking is that it aims to make Emacs
> appeal to people -- I think it is rather the other way around.
> Certain people appeal to Emacs: certain kinds of people like Emacs
> and the way it is set up, and they change it to suit their needs.
I worked for years as a special ed teacher and I learned that people have
different learning styles. It's not just learning, but it's perceiving and
working as well. Some people will always do better with a command line and
some will always do better with a GUI with point-and-click. That doesn't
mean one is smarter than the other or one is a true geek and one isn't.
It's just the way our brains are wired.
Emacs appeals to the type of personality that is often a hard core
programmer. It works for those that want to customize everything and have
full control over their environment AND do well with a command line rather
than a more visual and graphic environment. For those, emacs is probably
the best program for them.
Some people prefer to drive a Miata and some prefer a Dodge Ram. One isn't
better than the other, they're just different. Trying to make a Dodge Ram
look like a convertible so Miata lovers will want to use it is a waste.
It'll never be a Miata and the more people try to make it adaptable so it
can be one, the more they ruin what's special about it.
The more emacs is adapted for the non-technical, the more it'll lose what
makes it special and a good fit for programmers.
> Among your changes, I found none that made sense to me, a person who
> used Unix before Windows became widely used. For people like me, who
> always preferred Unix, changes like changing "buffer" to "opened file"
> seem inefficient and unnecessary.
It seems to me that is the kind of person emacs is written for. What will
it gain if a large number of non-technical people start using it in
a "non-emacs" mode?
> Sorry -- this totally falls flat. It won't make Emacs more widely
> used. The only thing that will make Emacs more widely used is making
> people aware of it; as soon as I became aware of Emacs (from reading
> Wikipedia, ironically), I began using it and I knew I was stuck with
> it. It's not even important for the survival of Emacs that it be more
> widely used -- it was never important in the last thirty years of its
> history, why should it be important now that Microsoft Word is so
> widely used?
Let those who need Word use it. To try to change emacs into something it
isn't is ignoring what makes it special.
Hal
Galen Boyer
> The problem with this line of thinking is that it aims to make Emacs
> appeal to people -- I think it is rather the other way around.
> Certain people appeal to Emacs: certain kinds of people like Emacs
> and the way it is set up, and they change it to suit their needs.
Emacs will always be for people who like to be able to constantly fiddle
with their environments which continues to increase the efficiency with
which they perform their tasks, increasing the # of tasks they can
perform and therefore increasing the # of peers it would take to equal
the amount of work they alone perform. Most other environments will be
for those just trying to perform their tasks and staying even with the
average proficiency chart.
--
Galen Boyer
Gian Uberto Lauri
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "GB" == Galen Boyer <galen...@yahoo.com> writes:
GB> Most other environments will be for those just trying to perform
GB> their tasks and staying even with the average proficiency chart.
Alleluja, brother!
(just unleashed the power of the True One Editor surprising the rest
of the workgroup)
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a fn...@rat.vg
Harry George
"constantly fiddle"
I've used emacs since the 1980's. I've used it for text, xml, html
markups, programming in many languages, and natural languages. In a
few cases I've "fiddled" with the environment. I've even written a
"mode". But it has never been "constantly". One does the setup, and
then uses it day after day, year after year... until you have a new
need, in which case you re-tune your settings and then go back to
work.
"trying to perform their tasks...average proficiency"
Aye, there's the rub. As Fred Brooks and others repeatedly point out,
there is little room in programming for average proficiency.
I don't mind folks using any editor they want, as long as they are
proficient. In those cases, I have no problem doing Extreme
Programming with them -- code a bit, save, the other guy codes a bit.
But when someone uses vi and then forgets how to do block moves, or
uses eclipse and bogs down the session, or uses MS Notepad and can't
enforce language-specific indents, I get frustrated.
--
Harry George
PLM Engineering Architecture
David Kastrup
> I don't mind folks using any editor they want, as long as they are
> proficient. In those cases, I have no problem doing Extreme
> Programming with them -- code a bit, save, the other guy codes a
> bit. But when someone uses vi and then forgets how to do block
> moves, or uses eclipse and bogs down the session, or uses MS Notepad
> and can't enforce language-specific indents, I get frustrated.
My favorite killing offence is /* vi:set ts=4: */.
--
David Kastrup
Matthias Buelow
> My favorite killing offence is /* vi:set ts=4: */.
This is apparently the default setting in many of the so-called "IDE"s
today.. I think it's another unwelcome poison gift from the ignorant
M$FT world (I suspect some primitive Windoze IDE which couldn't
differentiate between TAB and indent probably offered the programmer
changing the tabwidth as the only method for changing indentation, and
then this method got stuck...)
F'up to comp.emacs.
Xah Lee
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: The Terminology “buffer” and “keybinding” is good as they are.
A: The terminology “buffer” or “keybinding”, are technical terms
having to do with software programing. The term “keybinding” refers to
the association of a keystroke with a command in a technical, software
application programing context. That is to say, a programer “bind” a
keystroke to a command in a software application. The term “buffer”
refers to a abstract, temporary area for storing data, in the context
of programing or computer science.
These terms are irrelevant to the users of a software application.
As a user of a text editor, he works with files. The terms “opened
file” or “untitled file” are more appropriate than “buffer”. Since
emacs is also used for many things beside reading files or writing to
files, for example, file management, ftp/sftp, shell, email, irc etc.,
the proper term can be “panel”, “window”, or “work area”.
And, the term “keyboard shortcut” refers to typing of a key-
combination to activate a command. It is also more appropriate than
“binding” or “keybinding”.
Although concepts like “buffer” and “keybinding” are seemingly
interchangeable with “panel” or “keyboard shortcut”, but their
contexts set them apart. This is why in all modern software
application's user documentations, terms like “buffer” or “keybinding”
are not to be seen but “windows, panes, and keyboard shortcuts”.
The reason emacs uses the technical terminologies throughout is
because when emacs started in the 1970s, there really isn't any other
text editors or even software applications. And, Emacs users consists
of solely computer scientists and programers, and there are not many.
Changes in society are always resisted by old timers, but it is also a
main element behind progress. This terminology issue may seem trivial,
but its importance lies in making emacs palpable to the vast number of
people who ever need to use a computer to write.
Xah Lee
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Why should emacs want to be popular and why should emacs change to
conform the majority? We don't want emacs to be popular. We want
people to adopt emacs, not emacs adopting people.
A: This attitude has plagued unix and computer geekers for decades. In
the early 1990s (DOS and unix), tech geekers would sneer at graphical
menus and mouse, with hordes of reasons how pure text interface, the
command line, and or keyboard operations are sufficient and superior
than graphical user interface or using a mouse. This seems ridiculous
today, but such online forum messages are common.
The reason for these type of attitude, is almost never a sensible
alternative view about the topic in discussion, but a show of machismo
and superiority complex. (perhaps more than 95% of online computing
forum users are males, and majority of them are aged under 25.) The
person who utters such opinion, made sure in the way he writes that he
is a expert in the “more difficult to use” method or tools and would
prefer things not to be “dumbed down”.
It is silly to retort “Why should emacs want to be popular?”. It is
like asking “why do you want to live longer?” when someone is picky
about healthy food, or “why should you want to look beautiful?” when
someone dresses up. We want to improve software, not taking the
attitude of “we are more complex and unique and superior and we want
to keep dummies out”.
In software design, occasionally we are tied down with a design
decision, such that it has a popular vs elegant aspect. For example,
suppose we are designing a set of keyboard shortcuts for emacs and we
are faced the question of whether to keep the copy/paste/undo/open etc
with the conventional C/V/Z/O etc keystrokes. Or, we can choose to
sacrifice user's familiarity of conventions but obtain a keyboard
shortcut set that is in some way more consistent, extensible, or
otherwise technically better.
If a design decision comes down to a pure popularity vs elegance and
everything else equal, then the decision might be based on our
philosophical dispositions or the software creator's ultimate goal.
However, it is not proper to pigeon-hole design issues into popularity
vs elegance.
Xah Lee
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Emacs's ways are technically superior. It should not change.
A: Emac's user interface, when compared to modern software
application's user interface, is complex and unusual, however, there's
no basis whatsoever of it being actually a superior design with
regards to any sensible metrics. (in fact, much of emacs's user
interface are due to historical reasons. That is, how computers are in
1980s.)
For example, let's consider emacs's system of keyboard shortcuts. For
a keyboard shortcut system, we might judge its quality based on
several aspects. Here are some examples of consideration:
* Is it easy to learn? (is it familiar to most people?)
* Is it easy to type? (is most frequently used commands easy to
type?)
* Is it easy to remember?
* Are more frequently used commands have the easier-to-type
shortcuts that less frequently used commands?
* Are most frequently used commands all have a keyboard shortcut?
* Can the shortcut system somehow be consistent and extensible to
cover other user defined shortcuts?
Emacs's keyboard shortcuts system, somewhat satisfies the last aspect,
but do very bad with respect to all the others. Emacs keyboard
shortcuts are perhaps one of the most difficult to learn among
software, and is also one of the most difficult to remember. The worst
aspect of emacs's keyboard shortcuts, is that it is ergonomically
painful. (Many emacs-using programer celebrities have injured their
hands with emacs. (e.g. Richard Stallman, Jamie Zawinski), and emacs's
Cntl-x keyboard and Meta-x combinations are most cited as the major
turn-off to potential users among programers)
Computer keyboard is a hardware interface, and the mapping of commands
to the key press combinations can be considered from a Operation
Research point of view. The keyboard hardware itself can be designed
with consideration of ergonomics (that's why we have split and curved
keyboards), but consideration of what functions to map to what key
presses is also non-trivial if the software has large number of
functions or if the software is mission critical. Think of it this
way, consider a airplane cockpit, filled with knobs, dials, buttons,
and switches. Now, if your job is to map the airplane control
functions to these switches, what are the things to consider for a
optimal map?
If we take careful consideration on creating a keyboard shortcut
system for emacs, it is actually easy to create a system that are
purely superior in some technical sense than the ad-hoc Emacs's ways.
Aside from keyboard shortcuts system, Emacs's other user interfaces
are also questionable. For example, one major aspect of emacs
operation is that it uses a single window for multiple purposes and
files. Emacs is this way not because of a design decision, but rather
due to historical reasons. Computer resources in the 1980s are very
limited. When emacs is around, graphical system of showing “windows”
is not practically available, and the emacs's method of using the
screen (the textual-based-monitor) for presenting multiple tasks
(“buffers”) is actually a very advanced user interface design not
available in software of that era. When graphical systems becomes
practical in the 1990s, drawing a window takes a lot memory, and
opening multiple windows is slow and inpractical.
Modern software interface (say, post 2000) usually uses one window per
file (or task), and or show a tab if multiple task is to be
represented in a single window. However, in general, emacs doesn't
provide the tabs visual clue and still remained its old way of using a
single window for all files and tasks as its standard operation. As
far as user interface design is considered per se with respect to
today's computing standards, the emacs's way is inferior because it is
less intuitive. Arguably, emacs's operation methods may be more
efficient for expert users. 20 years ago, efficiency for expert users
may out weight the ease of use for majority of average users. But in
today computing era, computers are standard tools in every household,
efficiency and ease of use for general users is as important for
professional users. Even for professional users, it is openly
questionable that emacs's ways of operation induced by its default
user interface allows faster or more efficient operation than a user
interface based on modern software conventions.
Xah Lee
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Aquamacs already does what you want.
A: Aquamacs is a emacs variant based on emacs, for Apple's Macintosh
computers, created in about 2004 by David Reitter. Aquamacs modifies
emacs so that its user interface follows modern (Mac OS X)
conventions. For example, copy, paste, undo shortcuts are cmd-c, cmd-
v, cmd-z. Open file is cmd-o, saving is cmd-s. Close window is cmd-w.
There is a redo command by default, with shortcut cmd-shift-z. By
following a modern user interface, almost all points mentioned in this
article are fixed in Aquamacs. For more info, see: Wikipedia Aquamacs↗
and Aquamac's home page at: Aquamacs.org ↗
As a emacs variant, it does help in spreading the idea that emacs user
interface should be modernized. However, a third-party variant
software is irrelevant to the modernization issue.
For example, suppose Microsoft Word remained with its DOS era command
line interface, for example, file is opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load). Suppose Microsoft hired a
third party to release a variant called MS AquaWord. This would not
help Microsoft Word the software itself, and is likely to complicate
the issue around Microsoft Word.
Xah
x...@xahlee.org
∑ http://xahlee.org/
Joel J. Adamson
> Here are some Frequently Asked Questions about The Modernization of
> Emacs.
>
> They are slightly lengthy, so i've separated each item per post. The
> whole article can be found at
>
> http://xahlee.org/emacs/modernization.html
> ------------
>
> Q: The Terminology “buffer” and “keybinding” is good as they are.
>
> A: The terminology “buffer” or “keybinding”, are technical terms
> having to do with software programing. The term “keybinding” refers to
> the association of a keystroke with a command in a technical, software
> application programing context. That is to say, a programer “bind” a
> keystroke to a command in a software application. The term “buffer”
> refers to a abstract, temporary area for storing data, in the context
> of programing or computer science.
>
> These terms are irrelevant to the users of a software application.
Bologna.
Every computer user should see himself as a programmer.
> Changes in society are always resisted by old timers, but it is also a
> main element behind progress. This terminology issue may seem trivial,
> but its importance lies in making emacs palpable to the vast number of
> people who ever need to use a computer to write.
I'm a young-timer.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
John Nagle
>>>>>>"GB" == Galen Boyer <galen...@yahoo.com> writes:
>
>
> GB> Most other environments will be for those just trying to perform
> GB> their tasks and staying even with the average proficiency chart.
Oh, please. The "I'm so l33t" thing.
I used EMACS back in the LISP era, but really, that approach
is mostly of historical interest at this late date.
John Nagle
Ed
>
> I've used emacs since the 1980's.
> --
> Harry George
> PLM Engineering Architecture
I've asked this question on an emacs forum and got no response, so I
presume the answer is no, but I see, Harry, that you're a veteran, so
maybe you've seen things few others have.
Have you ever seen an, "Extract method," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its own method, with the appropriate method invocation left in
its place. If you could post a link, that'd be just champion.
.ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition
Lew
> On 19 Juni, 07:14, Harry George
>> I've used emacs since the 1980's.
> ...
>> --
>> Harry George
>> PLM Engineering Architecture
>
> I've asked this question on an emacs forum and got no response, so I
> presume the answer is no, but I see, Harry, that you're a veteran, so
> maybe you've seen things few others have.
>
> Have you ever seen an, "Extract method," function for emacs? Whereby
> you highlight some lines of code, press a key, and the code is whisked
> into its own method, with the appropriate method invocation left in
> its place. If you could post a link, that'd be just champion.
I googled about a bit and came up with
<http://bicyclerepair.sourceforge.net/>
linked from
<http://en.wikipedia.org/wiki/Refactoring>
I also looked at emacs's own "Info" pages and found this tidbit:
> `M-x c-beginning-of-defun'
> `M-x c-end-of-defun'
> Move point to the beginning or end of the current function or
> top-level definition. These are found by searching for the least
> enclosing braces. (By contrast, `beginning-of-defun' and
> `end-of-defun' search for braces in column zero.) If you are
> editing code where the opening brace of a function isn't placed in
> column zero, you may wish to bind `C-M-a' and `C-M-e' to these
> commands. *Note Moving by Defuns::.
>
> `M-a'
> Move point to the beginning of the innermost C statement
> (`c-beginning-of-statement'). If point is already at the beginning
> of a statement, move to the beginning of the preceding statement.
> With prefix argument N, move back N - 1 statements.
>
> In comments or in strings which span more than one line, this
> command moves by sentences instead of statements.
>
> `M-e'
> Move point to the end of the innermost C statement or sentence;
> like `M-a' except that it moves in the other direction
> (`c-end-of-statement').
You could, and I believe others have, create a macro to encapsulate these
actions with setting the mark and copying the region.
Here is a very promising-looking one that I found for C(**) and Java:
<http://xref-tech.com/speller/main.html>
GWMF.
--
Lew
spamfilt...@gmail.com
>
> Have you ever seen an, "Extractmethod," function for emacs? Whereby
> you highlight some lines of code, press a key, and the code is whisked
> its place. If you could post a link, that'd be just champion.
xrefactory does this. I tried it once. It's a bit pricey , though.
Giorgos Keramidas
> Here are some Frequently Asked Questions about The Modernization of
> Emacs.
>
> They are slightly lengthy, so i've separated each item per post. The
> whole article can be found at
>
> http://xahlee.org/emacs/modernization.html
> ------------
>
> Q: The Terminology “buffer” and “keybinding” is good as they are.
>
> A: The terminology “buffer” or “keybinding”, are technical terms
> having to do with software programing. The term “keybinding” refers to
> the association of a keystroke with a command in a technical, software
> application programing context. That is to say, a programer “bind” a
> keystroke to a command in a software application. The term “buffer”
> refers to a abstract, temporary area for storing data, in the context
> of programing or computer science.
>
> These terms are irrelevant to the users of a software application.
>
> As a user of a text editor, he works with files. The terms “opened
> file” or “untitled file” are more appropriate than “buffer”.
No they are not. See you may have a real *file* on a disk somewhere,
which is called 'opened file' or even 'untitled file'. Now isn't it
confusing to think in terms of made-up descriptiors, just because the
term 'buffer' seems alien?
Educating the user to avoid confusion in this and other cases of made
up, 'user-friendly' descriptions is not a good enough answer. If you
can educate the user about this sort of fine distinction between files
stored on a disk somewhere and files which are figments of the
imagination of Emacs, then I can educate them about 'buffer' too and be
done with it all.
The main difference is that I get to do it today, without the need for
multi-thousand-line changes in the source and documentation of Emacs and
its thousands of plugins.
Giorgos Keramidas
Apparently, we share at least part of that. My own favorite killing
offense is '/* vi:set ts=anything: */' :)
Bjorn Borud
|
| ----------------------------------------
| SIMPLE CHANGES
if I were to suggest improvements to Emacs, the things you mention are
probably among the last things I'd even consider. the problem with
Emacs is not really the nomenclature or the keybindings. the problem
is that it needs to do what it already does better.
My frustration with Emacs has mostly been that Emacs-Lisp is a bit too
limiting. It is too slow and the codebase is a bit messy. or at
least it was the last time I tried to do something in Emacs-Lisp a
couple of years ago. it would also be beneficial if there was a more
proper and well-organized standard library for Emacs to make
developing Emacs applications easier.
for programmers, Emacs is a pretty good editor already, but there is a
bit of a threshold for extending Emacs.
-Bjørn
Bjorn Borud
to be quite honest, your proposal seems to largely be based on
ignorance.
| A: The terminology “buffer” or “keybinding”, are technical terms
| having to do with software programing. The term “keybinding” refers to
| the association of a keystroke with a command in a technical, software
| application programing context. That is to say, a programer “bind” a
| keystroke to a command in a software application. The term “buffer”
| refers to a abstract, temporary area for storing data, in the context
| of programing or computer science.
the term "buffer" is used extensively outside the computer science
domain, so it is not a CS only term. in an editor it is actually a
quite sensible name since it abstracts things a bit. for instance a
buffer need not be associated with a file. nor does it make any
assumptions about the way it is displayed (as opposed to "window" or
"tab").
| These terms are irrelevant to the users of a software application.
they are very relevant to me, and I am very much a user of Emacs. and
again, they provide good abstractions.
| As a user of a text editor, he works with files.
learn Emacs before you criticize it. your assumption is wrong. in
emacs you work on _buffers_. buffers often do not have files
associated with them.
| The terms “opened file” or “untitled file” are more appropriate than
| “buffer”. Since emacs is also used for many things beside reading
| files or writing to files, for example, file management, ftp/sftp,
| shell, email, irc etc., the proper term can be “panel”, “window”, or
| “work area”.
"panel" and "window" refer to UI-elements. the buffer concept does
not map 1:1 to any of these. substituting "work area" for "buffer"
doesn't seem like a better abstraction. especially not if you see it
in the context of how Emacs relates to buffer contents.
| And, the term “keyboard shortcut” refers to typing of a key-
| combination to activate a command. It is also more appropriate than
| “binding” or “keybinding”.
why? if anything the term "shortcut" seems to imply that there is a
primary route to executing the function in question -- which more
often than not isn't the case. "keybinding" is a more precise term.
| Although concepts like “buffer” and “keybinding” are seemingly
| interchangeable with “panel” or “keyboard shortcut”, but their
| contexts set them apart.
they are interchangeable only if you have no idea what you are talking
about. you obviously have not bothered to have a proper look at Emacs
and think these things through properly.
| This is why in all modern software application's user
| documentations, terms like “buffer” or “keybinding” are not to be
| seen but “windows, panes, and keyboard shortcuts”.
most "modern" editors are built on different premises than Emacs and
many have a far simpler view of the world. extremely few of them even
come close to Emacs in defining what is in practice an operating
environment for applications. it makes sense to refer to "windows"
when in fact you are referring to windows. it doesn't make sense to
call buffers "windows" in Emacs; because they are not.
| The reason emacs uses the technical terminologies throughout is
| because when emacs started in the 1970s, there really isn't any other
| text editors or even software applications.
the abstractions you mention are sensible ones independently of when
they were concieved. just because other people came along later and
used different abstractions, doesn't mean that the ones used in Emacs
are wrong, inferior or inappropriate. if you had bothered to
understand Emacs properly, you would have found that some of the
abstractions used make a lot of sense in an editor.
| Changes in society are always resisted by old timers, but it is also a
| main element behind progress.
I've been in the computer industry long enough to have seen quite a
few cycles of re-invention. each cycle you learn something about
which inventions were good and which were bad. a common thread if you
look at the survival rate of products and ideas is that it isn't
always the best product or idea that wins.
often something new comes along to replace something old. sometimes
it is better than what you had before, but often it is not really
better, just different.
a good example is the web and the applications we implement in terms
of the web. take forums for instance. in a strict technical sense,
web-based forums are inferior to NNTP-based forums. (I am sure you can
make the comparison yourself). yet NNTP-based discussion is not
growing at the same rate as web forums. the net has chosen its
preferred technology, and it wasn't because the web-based discussion
forums were so much more technically refined that the majority chose
them.
for my uses, web forums are a huge step back from NNTP.
| This terminology issue may seem trivial, but its importance lies in
| making emacs palpable to the vast number of people who ever need to
| use a computer to write.
why? Emacs is a tool. if you don't like it: use something else. it
is that simple.
-Bjørn
Bjorn Borud
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.
there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".
for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".
applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.
Emacs is rather "user friendly", but not very "beginner friendly".
when I was first confronted with it, the sort of text editors I was
used to were Wordstar and derivatives of it. I was rather annoyed
that it didn't do what I expected, so I just used a different editor.
a few years later I bemoaned the fact that Emacs was so hard to use
during a conversation with a friend. he asked me if I had actually
made an effort to learn Emacs, which of course I hadn't. so I figured
I might as well give it a shot.
following the tutorial that comes with Emacs (and which is referred to
in the startup message) I spent a couple of hours one afternoon
learning the basics. already the next day I started using Emacs for
programming. the week after I had progressed to using it as my
newsreader (which I still do to this day) and eventually I started
reading my email in Emacs. perhaps two months after I had sat down to
learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly
simple stuff to make common programming tasks easier.
I found Emacs to be user friendly, but in a different sense than the,
IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
do more with less effort and provides a lot less friction than many
other developer tools I've used. at work I use it extensively, and we
have lots of neat extensions that really save a lot of time.
-Bjørn
Kaldrenon
Nothing he has said makes much sense, if any.
He's talking about advocacy of something unique and powerful by -
making it less unique and powerful-. Not merely catering to the lowest
common denominator, but promoting something as better -by making it
worse-. Who does that?
Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. How incredibly
stupid would it be for that inventor to then say, "I'm going to
convince people to buy my new vehicle, which is safer thanks to this
fifth wheel. But in order to market it, I'll take the fifth wheel off,
so it's more familiar and comfortable for them."
I'm very, very new to emacs. I used it a little this past year in
college, but I didn't try at all to delve into its features. I'm
starting that process now, and frankly, the thought of it changing -
already- upsets me. I don't feel like the program ought to change in
order to accommodate me. I'm excited about the prospect of mastering
something new and different. The fewer resemblances to the common-
denominator, extra-friendly stuff I've worked with in the past, the
better.
Emacs' uniqueness may hurt its adoption rate, but it still has plenty
of users, who are all perfectly happy with how things are done.
-Andrew
David Kastrup
> I'm very, very new to emacs. I used it a little this past year in
> college, but I didn't try at all to delve into its features. I'm
> starting that process now, and frankly, the thought of it changing -
> already- upsets me. I don't feel like the program ought to change in
> order to accommodate me.
Actually, the "E" in "Emacs" stands for "extensible". Part of the
appeal of Emacs is that you can change it to accommodate you.
> I'm excited about the prospect of mastering something new and
> different. The fewer resemblances to the common- denominator,
> extra-friendly stuff I've worked with in the past, the better.
>
> Emacs' uniqueness may hurt its adoption rate, but it still has
> plenty of users, who are all perfectly happy with how things are
> done.
Oh, but Emacs is not TeX: it _is_ being developed further. And some
changes are done in order to synchronize Emacs with the "other world"
where the latter has been oversleeping. For example, Emacs 23 will
internally use utf-8/Unicode as its encoding when it has used
emacs-mule up to now, a multibyte code of its own.
In spirit, this will not change Emacs much, yet it will remove
other-world friction and make Emacs more obviously the incarnation of
editing descended into this world.
--
David Kastrup
Kaldrenon
> Kaldrenon <kaldre...@gmail.com> writes:
> > I'm very, very new to emacs. I used it a little this past year in
> > college, but I didn't try at all to delve into its features. I'm
> > starting that process now, and frankly, the thought of it changing -
> > already- upsets me. I don't feel like the program ought to change in
> > order to accommodate me.
>
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Well put. Perhaps I should have said that I don't feel like the
program ought to change to "accommodate" -everybody-.
I know that Emacs is still being worked on, is still growing and
changing, and also that, because of its extensibility, anyone can
change it as they wish. In fact, if the OP wants Emacs to behave the
way he describes, I'm sure it's doable. But my statement was that the
changes he suggests are things that should not be enforced
universally, because not only is there nothing wrong with the things
he suggests changing, but the idea of enforcing uniform changes is not
entirely in the spirit of Emacs.
Bjorn Borud
| Just so everyone's clear:
|
| Nothing he has said makes much sense, if any.
(it'd be good if you explicitly specify who "he" is since pronouns by
nature are extremely context sensitive, and in this context an
unattentive reader might think you are referring to me. thanks :-).
| Emacs' uniqueness may hurt its adoption rate, but it still has plenty
| of users, who are all perfectly happy with how things are done.
I don't see popularity as a goal in itself. I am selfish. I only
care what the software can do for me and I think that this is the only
way to write good software: make something you'd want to use
yourself.
-Bjørn
Joel J. Adamson
> On Jun 20, 9:28 am, David Kastrup <d...@gnu.org> wrote:
>> Kaldrenon <kaldre...@gmail.com> writes:
>> > I'm very, very new to emacs. I used it a little this past year in
>> > college, but I didn't try at all to delve into its features. I'm
>> > starting that process now, and frankly, the thought of it changing -
>> > already- upsets me. I don't feel like the program ought to change in
>> > order to accommodate me.
>>
>> Actually, the "E" in "Emacs" stands for "extensible". Part of the
>> appeal of Emacs is that you can change it to accommodate you.
>
> Well put. Perhaps I should have said that I don't feel like the
> program ought to change to "accommodate" -everybody-.
>
The point is that the responsibility to customize is on the user. All
the developers need to do is continue providing the most customizable
piece of software around. If we place the responsiblity to customize
on the developer, then he develops a piece of software customized for
himself; that wouldn't be Emacs.
Which brings me to another point: as someone already said, you could
fork the code and make all these changes, but then it would be
something else, it would stop being Emacs.
And it would stop being cool.
Ed
But, Lew: GWMF?
- Gardner Winter Music Festival? (You have to love the black'n'white
photo on the right at: http://www.gwmf.org/)
- Generalized Whitening-Matched Filter?
- http://www.goatworld.com/gwmf.shtml ????
Twisted
Someone is charging money for an emacs addon? Are they nuts? A lot of
people won't touch emacs with a ten foot pole, and emacs is free. How
many would actually pay for something that's useless without emacs?
Especially given the near-certainty that the price is almost pure
profit margin...
Twisted
> The point is that the responsibility to customize is on the user.
Given that in its out-of-the-box configuration it's well-nigh unusable
without a printed-out "cheat sheet" of some kind, of the sort that
were supposed to have died out in the 80s, getting it customized poses
something of a catch-22 for anyone trying to get started using it.
Twisted
> I found Emacs to be user friendly, but in a different sense than the,
> IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
> do more with less effort and provides a lot less friction than many
> other developer tools I've used. at work I use it extensively, and we
> have lots of neat extensions that really save a lot of time.
Being beginner-friendly doesn't have to be at the expense of power or
expert-user usability.
On the other hand, being actively beginner-hostile leads to nobody
adopting the tool. Then again, if you don't mind being the last
generation that'll ever use it, then I guess you're okay with that. If
it suits its existing users, the rest of us will just continue to use
something else.
I continue to suspect that there's an ulterior motive for making and
keeping certain software actively beginner-hostile; a certain macho
elitism also seen with light aircraft pilots and commented on at
www.asktog.com (exact URL escapes me; sorry).
Twisted
> Imagine that a man invents a vehicle that's far safer and more
> maneuverable than any existing vehicle. Imagine that the increased
> safety comes from the fact that it has five wheels. How incredibly
> stupid would it be for that inventor to then say, "I'm going to
> convince people to buy my new vehicle, which is safer thanks to this
> fifth wheel. But in order to market it, I'll take the fifth wheel off,
> so it's more familiar and comfortable for them."
Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. Gratuitously, he
also has his own peculiar ideas regarding how one should control this
vehicle, and instead of giving it a normal car steering wheel, brake,
and gas pedal, he gives it two stick-like left and right throttle
controls, which can be pulled back to brake and even reverse the car,
pushed forwards to accelerate it, and positioned differently to cause
the vehicle to rotate -- even to rotate in place, obviating the need
for three-point turns and simplifying parallel parking somewhat.
Unfortunately, nobody used to a normal car is remotely comfortable
with these controls. They have a very steep learning curve and
numerous accidents result. It turns out there's even a conversion kit
available for replacing them with a normal steering wheel, brake, and
gas pedal, but getting the conversion kit without crashing on the way
to where you get it proves problematic because of the same unusual
controls you're trying to replace. All of the driving schools, of
course, teach the usual wheel-and-pedals method of controlling a motor
vehicle...
This seems to be a closer analogy with emacs versus normal Windows
text editors. Arguably even the weird controls are superior in some
way -- but only if you got used to them, which will never happen
because you'll abandon it for inability to be productive with it long
before that can happen, and also because the same clunky controls
hobble your access to the online help that would otherwise smooth the
path for you. The same problem plagues attempts to reconfigure the
controls to something more normal. And the computer-driving schools --
computer classes in ordinary school -- teach standard Windows UI
conventions (or their Macintosh equivalents, which correspond closely
to one another). If there is any formal training in emacs use, it's
effectively unobtainable due to obscurity and hard-to-findness,
geographical distance, expense, or even more than one of those
factors.
The above applies equally to vi and its derivatives, if not more so --
vi is like taking that same already-wacky car with the two separate
throttles and adding, in a fit of quaint nostalgia, the need to
actually crank-start its engine. ;)
BartlebyScrivener
> [this post is a excerpt from
> The Modernization of Emacs
> ----------------------------------------
> SIMPLE CHANGES
At the command line, change "emacs" to "gvim"
http://pinard.progiciels-bpi.ca/opinions/editors.html
rd
David Kastrup
> On the other hand, being actively beginner-hostile leads to nobody
> adopting the tool. Then again, if you don't mind being the last
> generation that'll ever use it, then I guess you're okay with
> that. If it suits its existing users, the rest of us will just
> continue to use something else.
>
> I continue to suspect that there's an ulterior motive for making and
> keeping certain software actively beginner-hostile; a certain macho
> elitism also seen with light aircraft pilots and commented on at
> www.asktog.com (exact URL escapes me; sorry).
You are babbling.
Emacs is amazingly beginner-friendly for the power and flexibility it
provides. You can sit a beginner at an Emacs session and have him
start editing and learning. You can't do the same, say, with vi or a
clone: the least you need is a vi helpsheet/cheat cup. With Emacs,
the help sheet is helpful but optional (most people would be eyed
strangely anyway if they kept a cheat barrel around at their
workplace).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Lew
> Thanks, all, for the answers.
>
> But, Lew: GWMF?
>
> - Gardner Winter Music Festival? (You have to love the black'n'white
> photo on the right at: http://www.gwmf.org/)
>
> - Generalized Whitening-Matched Filter?
>
> - http://www.gwmf.com/ ?
>
> - http://www.gwmf.de/host/ ?
>
> - http://www.goatworld.com/gwmf.shtml ????
Google was my friend.
--
Lew
Twisted
> Twisted <twisted...@gmail.com> writes:
> > On the other hand, being actively beginner-hostile leads to nobody
> > adopting the tool. Then again, if you don't mind being the last
> > generation that'll ever use it, then I guess you're okay with
> > that. If it suits its existing users, the rest of us will just
> > continue to use something else.
>
> > I continue to suspect that there's an ulterior motive for making and
> > keeping certain software actively beginner-hostile; a certain macho
> > elitism also seen with light aircraft pilots and commented on at
>
> You are babbling.
No, I am not. You, however, are being gratuitously insulting.
> Emacs is amazingly beginner-friendly for the power and flexibility it
> provides. [snip]
That's a joke, right? I tried it a time or two. Every time it was
rapidly apparent that doing anything non-trivial would require
consulting a cheat sheet. The printed-out kind, since navigating to
the help and back without already having the help displayed and open
to the command reference was also non-trivial.
Four hours of wasted time later, with zero productivity to show for
it, I deleted it. The same thing happened again, so it wasn't a bad
day or a fluke or a one-off or the particular version, either.
Twisted
> On Jun 17, 10:13 am, Xah Lee <x...@xahlee.org> wrote:
>
> > [this post is a excerpt from
> > The Modernization of Emacs
> > ----------------------------------------
> > SIMPLE CHANGES
>
> At the command line, change "emacs" to "gvim"
Out of the frying pan and into the fire...
Kaldrenon
> On Jun 20, 4:35 pm, David Kastrup <d...@gnu.org> wrote:
>
> > Twisted <twisted...@gmail.com> writes:
> > > On the other hand, being actively beginner-hostile leads to nobody
> > > adopting the tool. Then again, if you don't mind being the last
> > > generation that'll ever use it, then I guess you're okay with
> > > that. If it suits its existing users, the rest of us will just
> > > continue to use something else.
>
> > > I continue to suspect that there's an ulterior motive for making and
> > > keeping certain software actively beginner-hostile; a certain macho
> > > elitism also seen with light aircraft pilots and commented on at
>
> > You are babbling.
>
> No, I am not. You, however, are being gratuitously insulting.
>
> > Emacs is amazingly beginner-friendly for the power and flexibility it
> > provides. [snip]
>
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
>
> Four hours of wasted time later, with zero productivity to show for
> it, I deleted it. The same thing happened again, so it wasn't a bad
> day or a fluke or a one-off or the particular version, either.
I agree with you in that emacs is not inherently nor universally
beginner friendly. However, if you are trying to make the claim that
it is impossible to pick it up quickly, then I no longer agree with
you.
I still have a good deal to learn, even of the basics, but I've toyed
with it casually for a little bit (a total of two hours at most, but
almost certainly less) and I already know enough that finding out how
to do anything else IS trivial. It's not a program whose controls
throw themselves at you, exactly, but with a touch of patience and a
genuine interest in learning, it's not too bad.
Twisted
> > Twisted <twisted...@gmail.com> writes:
> > > I continue to suspect that there's an ulterior motive for making and
> > > keeping certain software actively beginner-hostile; a certain macho
> > > elitism also seen with light aircraft pilots and commented on at
>
> > You are babbling.
>
> No, I am not. You, however, are being gratuitously insulting.
I have that exact URL now -- http://www.asktog.com/columns/027InterfacesThatKill.html
The most relevant section is towards the bottom of the page.
Curiously, you can jump right to it with a text-find of the word
"girls".
David Kastrup
> On Jun 20, 4:49 pm, Twisted <twisted...@gmail.com> wrote:
>> On Jun 20, 4:35 pm, David Kastrup <d...@gnu.org> wrote:
>> > Twisted <twisted...@gmail.com> writes:
>> > > I continue to suspect that there's an ulterior motive for making and
>> > > keeping certain software actively beginner-hostile; a certain macho
>> > > elitism also seen with light aircraft pilots and commented on at
>> > >www.asktog.com(exactURL escapes me; sorry).
>>
>> > You are babbling.
>>
>> No, I am not. You, however, are being gratuitously insulting.
>
> I have that exact URL now --
> http://www.asktog.com/columns/027InterfacesThatKill.html
Utterly unrelated to Emacs.
Matthias Buelow
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
Ah, yes.. we live in a time where no-one seems to have the patience to
read documentation anymore. Maybe that's why there is such a scarcity of
good documentation with many "modern" software packages.
Here's a nice one from Ken Thompson:
``I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".''
Twisted
> I still have a good deal to learn, even of the basics, but I've toyed
> with it casually for a little bit (a total of two hours at most, but
> almost certainly less) and I already know enough that finding out how
> to do anything else IS trivial. It's not a program whose controls
> throw themselves at you, exactly, but with a touch of patience and a
> genuine interest in learning, it's not too bad.
I don't know what software you're describing, but it's obviously not
emacs, unless there have been some HUGE changes to (at minimum) the
help and pane-navigation (er, excuse me, "window"-navigation)
controls...
My experiences (with emacs and with a lot of other supposedly-
superior, usually unix-heritage software) put me in mind of an
analogy: fumbling around in a strange house in the dark without a
flashlight, banging into furniture frequently, trying to find a light
switch, but it turns out the switches are all spring-loaded. For some
reason (saving electricity and fighting the war against global
warming?) if you go to start doing anything else the light goes off
again immediately -- so you have to stand there holding the switch,
memorize the contents of the room, and then quickly do whatever you
needed to do before your memory of the room's layout and where things
are fades! Then back to the switch, or trip and fumble your way to a
different room's switch...wash, rinse, repeat...
Nobody would actually design a home (or a workplace) like that in a
trillion years, global warming be damned. So why do people still
sometimes design software like that?
Oh and did I mention that these houses' layouts are also totally
strange, with the living room on the top floor and the kitchen in the
basement, or other things of that nature, so you can't transfer any
knowledge of conventional home designs to aid in your navigation
there...and they are even all different from one another, nevermind
"normal" houses...
BTW, is anyone else finding Google Groups especially ornery of late? I
get all of the following, recurrently:
* I enter one reply in a thread, and it works. Then I go to make a
second reply, and I get a text box like one uses to enter a reply,
except evidently read-only -- I can select text but there is no
blinking cursor.
* The fix seems to be to navigate off the page and back.
Unfortunately, that then pops up some dialog. I think GG is trying to
protect me from losing unsaved changes, except that there are
obviously no unsaved changes to the (read-only!) form for me to lose!
* The "back" button is wonky -- it seems to require hitting back
*twice* to go back *one* page to the previous page of the thread or to
the newsgroup's thread index, if already on the first (or only) page.
* After *that*, "forward" behaves sometimes normally and sometimes as
"forward and then click a reply link on some random post"??
* Submitting a post results in the form disappearing and being
replaced by "The post was entered successfully". Of course, if it
turns out to have NOT been all that successful as evidenced from
refreshing the page or using an external newsserver (I have found one
read-only one suitable for verifying that a posting succeeded and
propagated beyond GG's server), there's no way to get back to the form
to try to resubmit the text, or even to recover it to the clipboard to
paste into a fresh form for a fresh attempt. So far, it's never
actually lied and claimed a posting was successful that wasn't, but
there's a first time for everything, and we all know the track record
for QA in the software industry ... and the way one of the more common
failure modes of software is silent failure, claiming success on
failure, claiming failure on success, or claiming one failure when a
different failure happened! (All the various forms of diagnostics
failure...) I guess I have to pre-emptively copy the form contents to
the clipboard before clicking submit, and preserve the clipboard
contents pending verification, or risk catastrophic data loss, because
GG can't be arsed to make a decent interface, or even to leave well
enough alone and stop constantly changing it.
Twisted
> Twisted <twisted...@gmail.com> writes:
> > On Jun 20, 4:49 pm, Twisted <twisted...@gmail.com> wrote:
> >> On Jun 20, 4:35 pm, David Kastrup <d...@gnu.org> wrote:
> >> > Twisted <twisted...@gmail.com> writes:
> >> > > I continue to suspect that there's an ulterior motive for making and
> >> > > keeping certain software actively beginner-hostile; a certain macho
> >> > > elitism also seen with light aircraft pilots and commented on at
>
> >> > You are babbling.
>
> >> No, I am not. You, however, are being gratuitously insulting.
>
> > I have that exact URL now --
> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> Utterly unrelated to Emacs.
I think it is quite relevant. Clunky computer interfaces may not be so
dramatically dangerous, but they certainly can hamper productivity.
Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
clunkiness, billions of dollars of potential productivity is lost
worldwide every *month*.
BartlebyScrivener
David Kastrup
> On Jun 20, 5:21 pm, David Kastrup <d...@gnu.org> wrote:
>> Twisted <twisted...@gmail.com> writes:
>> > On Jun 20, 4:49 pm, Twisted <twisted...@gmail.com> wrote:
>> >> On Jun 20, 4:35 pm, David Kastrup <d...@gnu.org> wrote:
>> >> > Twisted <twisted...@gmail.com> writes:
>> >> > > I continue to suspect that there's an ulterior motive for making and
>> >> > > keeping certain software actively beginner-hostile; a certain macho
>> >> > > elitism also seen with light aircraft pilots and commented on at
>> >> > >www.asktog.com(exactURLescapes me; sorry).
>>
>> >> > You are babbling.
>>
>> >> No, I am not. You, however, are being gratuitously insulting.
>>
>> > I have that exact URL now --
>> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> Utterly unrelated to Emacs.
>
> I think it is quite relevant. Clunky computer interfaces may not be
> so dramatically dangerous, but they certainly can hamper
> productivity.
But Emacs does not have a "clunky" interface.
> Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
> clunkiness, billions of dollars of potential productivity is lost
> worldwide every *month*.
You are spewing again.
Twisted
> Twisted wrote:
> > That's a joke, right? I tried it a time or two. Every time it was
> > rapidly apparent that doing anything non-trivial would require
> > consulting a cheat sheet. The printed-out kind, since navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
>
> Ah, yes.. we live in a time where no-one seems to have the patience to
> read documentation anymore. Maybe that's why there is such a scarcity of
> good documentation with many "modern" software packages.
Emacs does have documentation. The problem is you have to already know
a load of emacs navigation oddities^Wkeyboard commands to get to and
use it.
Also, basic tasks should not require consulting the documentation,
unless the application genre is new to the user. Basic tasks requiring
the uninitiated to consult the documentation is okay in 3D modeling
apps, given the "uninitiated" have used none before. Basic tasks
requiring the uninitiated to consult the documentation is absolutely
ludicrous in a text editor.
I count "consulting the documentation" as one of those basic tasks,
along with the fundamental editing, saving, loading, and searching
functionality (including, of course, "searching the documentation").
> ``I abhor a system designed for the "user", if that word is a coded
> pejorative meaning "stupid and unsophisticated".''
Yeah, and I abhor the elitist systems that are designed with the
philosophy that anyone who hasn't mastered years of arcane
memorization and training in just that one idiosyncratic system is /
ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
billion people have better uses for our time, such as buckling in and
being promptly productive, once we're out of high school or college,
and fully three and a quarter of us are at least as smart as average,
and so /ipso facto/ *not* "stupid and unsophisticated".
David Kastrup
> On Jun 20, 5:03 pm, Kaldrenon <kaldre...@gmail.com> wrote:
>> I still have a good deal to learn, even of the basics, but I've toyed
>> with it casually for a little bit (a total of two hours at most, but
>> almost certainly less) and I already know enough that finding out how
>> to do anything else IS trivial. It's not a program whose controls
>> throw themselves at you, exactly, but with a touch of patience and a
>> genuine interest in learning, it's not too bad.
>
> I don't know what software you're describing, but it's obviously not
> emacs, unless there have been some HUGE changes to (at minimum) the
> help and pane-navigation (er, excuse me, "window"-navigation)
> controls...
So what version are you babbling about?
Twisted
> But Emacs does not have a "clunky" interface.
That's for the everyday novice-to-intermediate user to decide. Your
gnu.org email address (and attitude) clearly marks you as not a normal
user, and so your opinion doesn't count.
David Kastrup
> On Jun 20, 5:22 pm, Matthias Buelow <m...@incubus.de> wrote:
>> Twisted wrote:
>> > That's a joke, right? I tried it a time or two. Every time it was
>> > rapidly apparent that doing anything non-trivial would require
>> > consulting a cheat sheet. The printed-out kind, since navigating to
>> > the help and back without already having the help displayed and open
>> > to the command reference was also non-trivial.
>>
>> Ah, yes.. we live in a time where no-one seems to have the patience to
>> read documentation anymore. Maybe that's why there is such a scarcity of
>> good documentation with many "modern" software packages.
>
> Emacs does have documentation. The problem is you have to already
> know a load of emacs navigation oddities^Wkeyboard commands to get
> to and use it.
Menus and toolbars exist.
> Also, basic tasks should not require consulting the documentation,
> unless the application genre is new to the user.
And they don't.
Really, what is the last version of Emacs you actually tried?
David Kastrup
> On Jun 20, 5:35 pm, David Kastrup <d...@gnu.org> wrote:
>
>> But Emacs does not have a "clunky" interface.
>
> That's for the everyday novice-to-intermediate user to decide.
And they do.
> Your gnu.org email address (and attitude) clearly marks you as not a
> normal user, and so your opinion doesn't count.
Your email address and attitude marks you as an anonymous troll.
Matthias Buelow
> Emacs does have documentation. The problem is you have to already know
> a load of emacs navigation oddities^Wkeyboard commands to get to and
> use it.
Yes, like hitting the F1 key.
> Yeah, and I abhor the elitist systems that are designed with the
> philosophy that anyone who hasn't mastered years of arcane
> memorization and training in just that one idiosyncratic system is /
> ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
> billion people have better uses for our time, such as buckling in and
> being promptly productive, once we're out of high school or college,
> and fully three and a quarter of us are at least as smart as average,
> and so /ipso facto/ *not* "stupid and unsophisticated".
Noone forces you to use either Unix or emacs (or vi, for that matter).
I don't really understand what your problem is.
Twisted
> ...spewing...babbling...
I won't dignify your insulting twaddle and random ad-hominem verbiage
with any more responses after this one. Something with actual logical
argumentation to rebut may be another matter of course.
One more GG issue: those stupid star ratings. So potentially
prejudicial. So easy to game, as evidenced by your managing to somehow
vote 82 times(!) against one of my posts in a matter of minutes. So
far I've found a less-impressive method to game them -- it's not hard
to get throwaway accounts elsewhere, send yourself there a gmail
invite, and create many GG accounts. Handy to get around their onerous
posting limits. Handy for stuffing the star-vote ballot boxes with
multiple votes, too, but there's no way I can see to generate 82 of
them that fast by that method, and that much logging in and out in
that short a time using different accounts but from just one IP
address is sure to come up on Google's radar somehow, with
unpredictable but probably bad results. How did you do it? I'm
guessing they stop the link for voting appearing as a usable link on
the page for a) your own posts and b) the ones you've voted for, but
the link's URL still works, so if you use a script to keep fetching
the appropriate URL ...
Cor Gest
Some entity, AKA Twisted <twist...@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> On the other hand, being actively beginner-hostile leads to nobody
> adopting the tool. Then again, if you don't mind being the last
> generation that'll ever use it, then I guess you're okay with that. If
> it suits its existing users, the rest of us will just continue to use
> something else.
> I continue to suspect that there's an ulterior motive for making and
> keeping certain software actively beginner-hostile; a certain macho
> elitism also seen with light aircraft pilots and commented on at
> www.asktog.com (exact URL escapes me; sorry).
Of course! real tools are not for wannabees.
Just like there are a lot of people that have a shed full off the most
modern power-tools that money can buy from the local DIY-Market,
but cannot build a chickencoop if their life depended on it.
If you are to lazy to learn how to use any tool, it will not serve
you in any usefull manner.
But if you are to dumb to grok it, it's useless anyway.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
Dave Hansen
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Actually, though Emacs is the epitome of extensibility, the "E" stands
for "Editor." "EMACS" is simply short for Editor MACroS, and was
originally implemented as a set of TECO macros.
There's also the joke that EMACS stands for Esc Meta Alt Ctrl Shift,
due to it's (often overwhelmingly) large and sometimes complex set of
keystroke combinations used to invoke various editing functions. This
view is usually put forth by the vi camp during editor wars.
Speaking of which, vi is a piece of wombat do. ;-)
Regards,
-=Dave
Daniel Dyer
There are dozens of alternative interpretation for "EMACS".
http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
My favourite:
Elsewhere Maybe All Commands are Simple
Dan.
--
Daniel Dyer
http//www.uncommons.org
Martin Gregorie
> This seems to be a closer analogy with emacs versus normal Windows
> text editors.
>
primitive functions and are further hampered by having an interface that
required frequent time wasting hand transfers from keyboard to mouse
because, if they provide keyboard equivalents at all, these are
remarkably unmemorable and/or undocumented.
Ask anybody who used early versions of Word and you'll hear just how
much faster Word for DOS 5 was than any of its Windows incarnations.
This was because all commands were keystrokes so a skilled typist could
keep both hands on the keyboard all the time. WinWord's interface is a
clunker by comparison.
As for documentation, lets look at vi. Not a great editor, but every
*nix variation has it installed and any fool can learn to use it in
about 2 hours flat and it does at least have good pattern matching.
Can't find its documentation? Never heard of manpages ("man vi") or
apropos ("apropos vi")? My copy of vi understands ":help" and tells you
so if you start it without any arguments.
Amongst its benefits are that you can do anything its capable of by
using only a standard QUERTY keyboard plus ESC - no function keys, etc
are needed - which can save your bacon if somebody misconfigured your
console or the computer is dieing. Beyond that it has user-configurable
KEY BINDINGS so you can also set it up to suit both yourself and that
fancy keyboard in front of you.
> Arguably even the weird controls are superior in some
> way -- but only if you got used to them,
>
You mean that Alt-Esc or Windows-e aren't weird? How long is it since
you tried to use Windows with a dead mouse? There are a set of arcane
keystrokes to replace anything you can do with a mouse but I bet 99% of
windows users don't know any of them apart from TAB and CTRL-ALT-DEL.
> The above applies equally to vi and its derivatives, if not more so --
> vi is like taking that same already-wacky car with the two separate
> throttles and adding, in a fit of quaint nostalgia, the need to
> actually crank-start its engine. ;)
>
If you can't learn enough vi to get by with in half a morning you're
probably well out of your depth here on comp.lang.java.programmer.
Oh, I forgot: you don't read manuals so you ARE out of your depth.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Gabriel Genellina
> Speaking of which, vi is a piece of wombat do. ;-)
Would you all please stop posting (and crossposting) about something that
is mostly off topic for 80% of the groups involved?
Or is someone going for the Longest Off Topic Thread Of The Year Award?
--
Gabriel Genellina
Evan Klitzke
> Amongst its benefits are that you can do anything its capable of by
> using only a standard QUERTY keyboard plus ESC - no function keys, etc
> are needed - which can save your bacon if somebody misconfigured your
> console or the computer is dieing.
While it is true that the original incarnation of vi only uses the
"regular" keyboard keys and the escape key, to make vi not painful to
use there are a whole slew of commands that have been added in vim and
other vi clones to add basic features, and many of these commands use
Ctrl (or some other function key). For example, the original vi lacks
a redo command (!), and consequently the redo command sequence in vim
is Ctrl-r. I don't think nearly as many people would use vi if none
of the Ctrl sequence commands present on modern versions of vi were
available due to the lack of features like this one.
--
Evan Klitzke <ev...@yelp.com>
Evan Klitzke
> On 6/20/07, Martin Gregorie <mar...@see.sig.for.address> wrote:
> > using only a standard QUERTY keyboard plus ESC - no function keys, etc
> > are needed - which can save your bacon if somebody misconfigured your
> > console or the computer is dieing.
>
> "regular" keyboard keys and the escape key, to make vi not painful to
> use there are a whole slew of commands that have been added in vim and
> other vi clones to add basic features, and many of these commands use
> Ctrl (or some other function key). For example, the original vi lacks
> a redo command (!), and consequently the redo command sequence in vim
> is Ctrl-r. I don't think nearly as many people would use vi if none
> of the Ctrl sequence commands present on modern versions of vi were
> available due to the lack of features like this one.
Sorry to reply to my own message, but if I didn't someone else would
have corrected me! It's not that the original vi didn't have redo, but
it didn't have multiple undo, so using undo twice would effectively
function as a redo.
--
Evan Klitzke <ev...@yelp.com>
kaens
> En Wed, 20 Jun 2007 19:33:29 -0300, alguien escribió:
>
>
> is mostly off topic for 80% of the groups involved?
> Or is someone going for the Longest Off Topic Thread Of The Year Award?
>
> --
> Gabriel Genellina
>
> http://mail.python.org/mailman/listinfo/python-list
>
I for one, am finding the thread interesting, and it can be argued
that a discussion about text-editors is relevant in a group about any
programming language - although this specific topic (Modernization of
emacs) is certainly not VERY relevant to python, except in the sense
that a lot of people are seeing python as their first programming
language and need to figure out what editor to use (emacs being a very
powerful one with a steep learning curve)
Anyhow, the topic isn't a flamewar, and it's generating well-thought
out discussion - is it that big of a deal?
David Kastrup
> On Jun 20, 12:39 pm, jadam...@partners.org (Joel J. Adamson) wrote:
>> The point is that the responsibility to customize is on the user.
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
"Catch 22" is the right phrase here: just catch Emacs 22 and get
started. Its out-of-the-box configuration is quite sensible.
What was the last version you said you actually tried out?
--
David Kastrup
David Kastrup
> On Jun 20, 5:37 pm, David Kastrup <d...@gnu.org> wrote:
>> ...spewing...babbling...
>
> I won't dignify your insulting twaddle and random ad-hominem verbiage
> with any more responses after this one. Something with actual logical
> argumentation to rebut may be another matter of course.
>
> One more GG issue: those stupid star ratings. So potentially
> prejudicial. So easy to game, as evidenced by your managing to somehow
> vote 82 times(!) against one of my posts in a matter of minutes.
It has not occured to you that actually thousands of people read those
postings? And they are heavily crossposted to boot (redirecting
followup to comp.emacs, I would suggest everybody else do the same).
And you have really nothing worthwhile to contribute. So if there is
some rating system (I don't use Google Groups so can't tell) in place,
your postings would certainly be good candidates for downrating.
Not that this posting of mine is much better, and actually the
followup-to comp.emacs would indicate that this is about Emacs.
However, you have still not given any information about what, if any,
version of Emacs your very vaguely expressed experiences are supposed
to have come from.
> So far I've found a less-impressive method to game them -- it's not
> hard to get throwaway accounts elsewhere, send yourself there a
> gmail invite, and create many GG accounts.
And you wonder that people don't find it worthwhile reading you...
> Handy to get around their onerous posting limits. Handy for stuffing
> the star-vote ballot boxes with multiple votes, too, but there's no
> way I can see to generate 82 of them that fast by that method, and
> that much logging in and out in that short a time using different
> accounts but from just one IP address is sure to come up on Google's
> radar somehow, with unpredictable but probably bad results.
Uh, is there some monetary compensation for star ratings? Or what's
the deal? Really, if somebody can come up with a better group for
followups, feel free to direct there.
> How did you do it? I'm guessing they stop the link for voting
> appearing as a usable link on the page for a) your own posts and b)
> the ones you've voted for, but the link's URL still works, so if you
> use a script to keep fetching the appropriate URL ...
What a crazy obsession.
--
David Kastrup
Sascha Bohnenkamp
i e n o w
g g d n a
h a t p
t b i p
y n i
t o n
e u g
s s
l
o y
f
m
e
m
o
r
y
Sascha Bohnenkamp
> primitive functions and are further hampered by having an interface that
> required frequent time wasting hand transfers from keyboard to mouse
> because, if they provide keyboard equivalents at all, these are
> remarkably unmemorable and/or undocumented.
well ultra-edit, textpad, source-insight etc. pp are better than that
(and run on windows)
anno...@radom.zrz.tu-berlin.de
> Speaking of which, vi is a piece of wombat do. ;-)
You can have Emacs when you pry it from my cold hypertrophied
escape-pressing pinky!
Anno
Karsten Wutzke
Yaawn!
> Xah
> x...@xahlee.org
> ∑http://xahlee.org/
Hmm I just had to think about the C64/Amiga etc. game "California
Games"... The game displayed a comment when the player broke his neck
the 13th time when BMXing:
"Geek of the week!"
Karsten
notbob
> You can have Emacs when you pry it from my cold hypertrophied
> escape-pressing pinky!
LOL!....
nb
Martin Gregorie
I said MOST, not all!
To your list I'd add PFE and a Windows port of microEmacs, which has
almost nothing in common with EMACS except some key bindings.
But to return to your point: how many Windows users actually install the
editors we've listed? I bet most never get past Wordpad. I've even found
people using Word, of all things, to edit BAT files and program source.
I'd give long odds that Windows users who use editors other than Wordpad
are using the one that came with whatever IDE they've installed, simply
because integrated editors are much more common in Windows-only IDEs
that they are on *nixen. My guess is that this is because the standard
editors (Wordpad, edlin) are so bad.
Roy Smith
wrote:
> Kaldrenon <kald...@gmail.com> writes:
>
> > I'm very, very new to emacs. I used it a little this past year in
> > college, but I didn't try at all to delve into its features. I'm
> > starting that process now, and frankly, the thought of it changing -
> > already- upsets me. I don't feel like the program ought to change in
> > order to accommodate me.
>
> Actually, the "E" in "Emacs" stands for "extensible". Part of the
> appeal of Emacs is that you can change it to accommodate you.
Actually, the "E" in Emacs stands for "Editor". And the macs part stands
for "Macros". As in "Editor Macros". It started out as a bunch of macros
written in TECO.
David Kastrup
It's not like I did not know this. Don't ask me what got into my head
here.
--
David Kastrup
Bjorn Borud
|
| Given that in its out-of-the-box configuration it's well-nigh unusable
| without a printed-out "cheat sheet" of some kind, of the sort that
| were supposed to have died out in the 80s, getting it customized poses
| something of a catch-22 for anyone trying to get started using it.
indeed, not adhering to the half a dozen keybinding and menu
conventions that most newer applications use on OSX and Windows today
is not ideal UI design, but it doesn't really present that much of a
problem either; so it ends up being a non-issue to any regular user.
(actually, it isn't merely a case of changing some keybindings and
names -- the problem is that Emacs has a bunch of concepts that are
not easily mapped to trivial editor semantics, so it would be hard to
change without causing further confusion).
Emacs isn't really meant for the casual user and there are editors far
better suited for those who think spending an afternoon learning it is
too much. (compare to VI or VIM, which probably takes even a bit
longer to grasp, but which is beautifully practical once you
understand how it works. there's this good tech-talk given by Bram
Moolenaar available¹ on about text editing and VIM).
¹) http://video.google.com/videoplay?docid=2538831956647446078
-Bjørn
Bjorn Borud
|
| As for documentation, lets look at vi. Not a great editor, but every
| *nix variation has it installed and any fool can learn to use it in
| about 2 hours flat and it does at least have good pattern matching.
there's also the "info" system in Emacs, which not only covers Emacs
itself, but usually also a lot of documentation available for Emacs
extensions and other programs. again, this predates a lot of things
that people are used to today, so just because it seems (and sometimes
is) a bit more fiddly, it must necessarily be inferior.
the most common theme when people have to choose between products is
that they are not really comparing what it is like to use the products
like they were intended -- they are merely underlining that X is not
Y. for instance, Linux has come a long way in addressing the needs of
desktop users, yet some people refuse to use Linux because it doesn't
behave *exactly* like Windows (as if that was a worthwhile goal) and
they are too lazy or don't think they can manage, to learn a new
system.
-Bjørn
Bjorn Borud
|
| http://www.debian-administration.org/polls/89
this is hardly surprising. I use both editors. for most sysadmin
tasks I use vi(m). for programming i use Emacs.
in part out of old habit (most UNIX systems had vi installed) and
partly because vi(m) is faster (which makes it more suitable when you
just need to change a couple of lines in a file).
for programming I use Emacs since I have a gazillion extensions I use
while programming that I don't even think about anymore. from various
forms of automated text completion to syntax checking/highlighting, to
enforcing style guides, look up symbol relationships, compile, debug
etc.
so if the context was system administration, I'd vote for vi as
well. if the context was programming I'd vote Emacs.
-Bjørn
David Kastrup
> [BartlebyScrivener <bscriv...@gmail.com>]
> |
> | http://www.debian-administration.org/polls/89
>
> this is hardly surprising. I use both editors. for most sysadmin
> tasks I use vi(m). for programming i use Emacs.
>
> in part out of old habit (most UNIX systems had vi installed) and
> partly because vi(m) is faster (which makes it more suitable when you
> just need to change a couple of lines in a file).
The idea is to start Emacs once and use it for everything.
> so if the context was system administration, I'd vote for vi as
> well. if the context was programming I'd vote Emacs.
You know you can use something like
C-x C-f /su::/etc/fstab RET
(or /sudo::/etc/fstab) in order to edit files as root in a normal
Emacs session?
--
David Kastrup
Lew
>> so if the context was system administration, I'd vote for vi as
>> well. if the context was programming I'd vote Emacs.
David Kastrup wrote:
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
I've been using emacs for something like twenty years and never knew that before.
I like the built-in therapist in emacs.
--
Lew
Robert Uhl
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
I don't see that. C-h t is your friend if you're starting out. The
only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
everything else simple text editing needs works as expected (arrow keys,
backspace and so forth). Granted, text-mode is friendlier than
fundamental-mode. Still, as a pico replacement emacs works well
enough--and as the user continue to works, he discovers more and more
functionality, eventually having a 10,000-line .emacs...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Listening to someone who brews his own beer is like listening to a
religious fanatic talk about the day he saw the light.
--Ross Murray, Montreal Gazette, 1991
Bjorn Borud
|
| Being beginner-friendly doesn't have to be at the expense of power or
| expert-user usability.
depends on your definition of "expert". :-)
| On the other hand, being actively beginner-hostile leads to nobody
| adopting the tool. Then again, if you don't mind being the last
| generation that'll ever use it, then I guess you're okay with that.
obviously I lie awake dreading the day this happens. on my tombstone
will say "here lies the last Emacs user on earth. M-x rip".
-Bjørn
Bjorn Borud
|
| Emacs does have documentation. The problem is you have to already know
| a load of emacs navigation oddities^Wkeyboard commands to get to and
| use it.
that, or just start Emacs and follow the instructions that appear on
the screen.
indeed, I *am* aware that something demanding an attention span in
excess of 3 seconds is a bit of a tall order for most users today.
-Bjørn
Joel J. Adamson
> On Jun 20, 12:39 pm, jadam...@partners.org (Joel J. Adamson) wrote:
>> The point is that the responsibility to customize is on the user.
>
> Given that in its out-of-the-box configuration it's well-nigh unusable
> without a printed-out "cheat sheet" of some kind, of the sort that
> were supposed to have died out in the 80s, getting it customized poses
> something of a catch-22 for anyone trying to get started using it.
Again, I have to point out that I had a different experience. I did
the tutorial, and somehow immediately I understood how to customize.
I don't remember having any difficulty with Emacs other than not
liking the way it looked -- that's because I was on Windows (I later
found out). I soon fixed that problem. I didn't need a cheat-sheet,
since the help files are _actually_ _helpful_ unlike those "Help"
(=advertising) files on most other pieces of software.
My point is that I'm the sort of person that has a mind set up for
Emacs. I had none of the difficulties that someone else might have,
who's used to other kinds of software.
However, I'll also point out that my wife has used Emacs a couple
times, and she's never done more than point and click with a computer,
and she's had no frustration whatsoever.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
notbob
> You know you can use something like
> C-x C-f /su::/etc/fstab RET
> (or /sudo::/etc/fstab) in order to edit files as root in a normal
> Emacs session?
As I understand it, this will only work for ver 22 and later or if
you have tramp(?) installed. I have 2.3.1 (no tramp) and all I get is:
ftp> open su
ftp: su: Unknown host
I'm looking at upgrading to 22 for a couple other features, too.
nb
Joel J. Adamson
> On Jun 20, 5:03 pm, Kaldrenon <kaldre...@gmail.com> wrote:
>> I still have a good deal to learn, even of the basics, but I've toyed
>> with it casually for a little bit (a total of two hours at most, but
>> almost certainly less) and I already know enough that finding out how
>> to do anything else IS trivial. It's not a program whose controls
>> throw themselves at you, exactly, but with a touch of patience and a
>> genuine interest in learning, it's not too bad.
>
> I don't know what software you're describing, but it's obviously not
> emacs, unless there have been some HUGE changes to (at minimum) the
> help and pane-navigation (er, excuse me, "window"-navigation)
> controls...
We're talking about Emacs. In particular we're referring to
C-h t
C-h i
C-h ?
Or, since Emacs is customizable, for me it would be
<f1> t
<f1> i
<f1> ?
David Kastrup
> Bjorn Borud <borud...@borud.no> writes:
>>> so if the context was system administration, I'd vote for vi as
>>> well. if the context was programming I'd vote Emacs.
>
> David Kastrup wrote:
>> You know you can use something like
>> C-x C-f /su::/etc/fstab RET
>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>> Emacs session?
>
> I've been using emacs for something like twenty years and never knew
> that before.
The package "tramp" will provide that (as well as editing files over
ssh, scp, rsync, telnet, plink...). It is already preinstalled in
Emacs 22.1, but can also be installed for earlier versions.
--
David Kastrup
David Kastrup
> Twisted <twist...@gmail.com> writes:
>
>> On Jun 20, 5:03 pm, Kaldrenon <kaldre...@gmail.com> wrote:
>>> I still have a good deal to learn, even of the basics, but I've toyed
>>> with it casually for a little bit (a total of two hours at most, but
>>> almost certainly less) and I already know enough that finding out how
>>> to do anything else IS trivial. It's not a program whose controls
>>> throw themselves at you, exactly, but with a touch of patience and a
>>> genuine interest in learning, it's not too bad.
>>
>> I don't know what software you're describing, but it's obviously not
>> emacs, unless there have been some HUGE changes to (at minimum) the
>> help and pane-navigation (er, excuse me, "window"-navigation)
>> controls...
>
> We're talking about Emacs. In particular we're referring to
>
> C-h t
> C-h i
> C-h ?
>
> Or, since Emacs is customizable, for me it would be
>
> <f1> t
> <f1> i
> <f1> ?
Huh? The latter are available by default on Emacs 22.1.
--
David Kastrup
David Kastrup
> On 2007-06-21, David Kastrup <d...@gnu.org> wrote:
>
>> You know you can use something like
>> C-x C-f /su::/etc/fstab RET
>> (or /sudo::/etc/fstab) in order to edit files as root in a normal
>> Emacs session?
>
> As I understand it, this will only work for ver 22 and later or if
> you have tramp(?) installed. I have 2.3.1 (no tramp) and all I get is:
>
> ftp> open su
> ftp: su: Unknown host
I should think that version 2.3.1 would not even try ftp. Is that on
Multics?
> I'm looking at upgrading to 22 for a couple other features, too.
You'll find that the last 30 years of development indeed make a
difference.
--
David Kastrup
Joel J. Adamson
>
> Here's a nice one from Ken Thompson:
>
> ``I abhor a system designed for the "user", if that word is a coded
> pejorative meaning "stupid and unsophisticated".''
That's a good one. It's going on my wall.
Joel J. Adamson
Joel J. Adamson
> Yeah, and I abhor the elitist systems that are designed with the
> philosophy that anyone who hasn't mastered years of arcane
> memorization and training in just that one idiosyncratic system is /
> ipso facto/ "stupid and unsophisticated". Most of us 6 and a half
> billion people have better uses for our time, such as buckling in and
> being promptly productive, once we're out of high school or college,
> and fully three and a quarter of us are at least as smart as average,
> and so /ipso facto/ *not* "stupid and unsophisticated".
>
You see, though, the problem is that computers are *not* easy to use.
People only say that they've been made easy to use in order to *sell*
things. The number one commodity in the technology business (with a
huge profit-margin attached to it) is "user-friendly." And it's
baloney! No one in my office that uses one of these supposedly
user-friendly machines thinks that it's actually easy to use. They
slam their keyboards and throw their hands up *every* day.
The only solution that really works is for people to _learn_ how to
use computers, and to accept that it will be a challenge.
And as for the arcane commands needed to get to the help page, their
on the splash screen. Have you used Emacs recently?
Lew
> My point is that I'm the sort of person that has a mind set up for
> Emacs. I had none of the difficulties that someone else might have,
> who's used to other kinds of software.
>
> However, I'll also point out that my wife has used Emacs a couple
> times, and she's never done more than point and click with a computer,
> and she's had no frustration whatsoever.
A new user of two hours' experience. A father of a six-year old whose child
hums along happily with emacs. A computer widow who "had no frustration
whatsoever" with it.
To the claim that "emacs is too hard for the beginner" we have a mounting pile
of steaming evidence that refutes. It may still be true that it is too hard
for some beginners, but then again the power cord can be too hard for some
people. (I used to help customers find the Big Red Switch when they first got
a computer. There were many who needed it.)
To the claim that emacs has arcane keystrokes comes the evidence that modern
revs have "normal" keystrokes like right-arrow, F1, Ctrl-End.
To the claim that the help is too hard to use comes the evidence that three
simple keystroke patterns are all one needs to know, and anecdotal evidence of
the help system's utility.
Some will refuse to face the truth. To the open-minded, let the facts speak
for themselves.
I bet Xah Les is all over smiles about how well his controversy bloomed.
--
Lew
notbob
> To the claim that "emacs is too hard for the beginner" we have a mounting pile
> of steaming evidence that refutes. It may still be true that it is too hard
> for some beginners......
I point them to jed. I, too, was overwhelmed by emacs, initially, but
can't stand vi so I had to do something. jed was my savior. It uses
many standard keys like backspace and the arrows, so newbs aren't so
confused. When I finally became comfortable with the std emacs
keystrokes I got O'Reilly's great book and ventured into emacs. Love
it. But, still a rank newb and still use jed and slrn a lot till I
can learn to configure emacs like I want it.
vi, the heart of evil!
nb
notbob
>
> I should think that version 2.3.1 would not even try ftp. Is that on
> Multics?
Slackware 10.1
nb
Lew
>> To the claim that "emacs is too hard for the beginner" we have a mounting pile
>> of steaming evidence that refutes. It may still be true that it is too hard
>> for some beginners......
notbob wrote:
> I point them to jed. I, too, was overwhelmed by emacs, initially, but
> can't stand vi so I had to do something. jed was my savior. It uses
> many standard keys like backspace and the arrows, so newbs aren't so
> confused.
You mean compared to the way emacs also uses the same "standard" keys, like
backspace and the arrows? How are the arrow keys in emacs more confusing than
the arrow keys in jed?
Your comment reads like you've missed most of this thread.
--
Lew
notbob
> Your comment reads like you've missed most of this thread.
This may be due to the fact I've missed most of this thread.
nb
Robert Uhl
>
>> Emacs is amazingly beginner-friendly for the power and flexibility it
>> provides. [snip]
>
> That's a joke, right? I tried it a time or two. Every time it was
> rapidly apparent that doing anything non-trivial would require
> consulting a cheat sheet. The printed-out kind, since navigating to
> the help and back without already having the help displayed and open
> to the command reference was also non-trivial.
C-h i, C-x b RET is non-trivial?!?
> Four hours of wasted time later, with zero productivity to show for
> it, I deleted it. The same thing happened again, so it wasn't a bad
> day or a fluke or a one-off or the particular version, either.
If you'd spent half an hour using the tutorial (helpfully displayed
right there when you start emacs), you could have saved three and a half
hours of wasted time. And you'd now be using an actual text editor,
which is often helpful.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The cover art on the O'Reilly tome isn't meant to anthropomorphize
sendmail itself after all; it's actually a subliminal warning that
one'd need to be bats to want to use sendmail. --Anthony de Boer