[this post is a excerpt from
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.
Xah xa*@xahlee.org
∑ http://xahlee.org/ 331  14657 
For the love of dogs, Xah, try to keep up. Aquamacs is an Emacs
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.orgwrote:
[this post is a excerpt from
The Modernization of Emacs, Xah Lee, 2006-04 athttp://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 “keyboardshortcut” in
emacs documentation. Use the term keybinding or binding only in a
technical context, such as in elisp documentation.
* Xah
* x...@xahlee.org
∑http://xahlee.org/
On Jun 17, 11:13 am, Xah Lee <x...@xahlee.orgwrote:
[snip]
Whoa. Xah posted something I agree with wholeheartedly. Imagine that.
Ever came to your mind that there are people (programmers and others)
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).
On Jun 17, 6:46 pm, Philipp Leitner <philipp.leit...@gmx.atwrote:
Ever came to your mind that there are people (programmers and others)
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).
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.
On 17 , 19:13, Xah Lee <x...@xahlee.orgwrote:
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.
There is a CUA-mode.
* 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/
>
* 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.
Xah Lee <xa*@xahlee.orgwrites:
----------------------------------------
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
Joel J. Adamson wrote:
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
Joel J. Adamson wrote:
Xah Lee <xa*@xahlee.orgwrites:
>----------------------------------------
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
On Mon, 18 Jun 2007, ja******@partners.org wrote:
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
>>>>Long count = 12.19.14.7.8; tzolkin = 7 Lamat; haab = 16 Zotz.
>>>>I get words from the Allmighty Great Gnus that
"GB" == Galen Boyer <ga*********@yahoo.comwrites:
GBMost other environments will be for those just trying to perform
GBtheir 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
Galen Boyer <ga*********@yahoo.comwrites:
On Mon, 18 Jun 2007, ja******@partners.org wrote:
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
"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
Harry George <ha************@boeing.comwrites:
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
David Kastrup wrote:
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.
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”. 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 xa*@xahlee.org
∑ http://xahlee.org/
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: 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 xa*@xahlee.org
∑ http://xahlee.org/
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: 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 xa*@xahlee.org
∑ http://xahlee.org/
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: 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 xa*@xahlee.org
∑ http://xahlee.org/
Xah Lee <xa*@xahlee.orgwrites:
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
Gian Uberto Lauri wrote:
>>>>>>"GB" == Galen Boyer <ga*********@yahoo.comwrites:
GBMost other environments will be for those just trying to perform
GBtheir 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
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.
..ed
-- www.EdmundKirwan.com - Home of The Fractal Class Composition
Ed wrote:
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
On Jun 19, 9:21 pm, Ed <iamfrac...@hotmail.comwrote:
>
Have you ever seen an, "Extractmethod," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its ownmethod, with the appropriatemethodinvocation left in
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.
On Tue, 19 Jun 2007 15:53:21 +0200, David Kastrup <da*@gnu.orgwrote:
>Harry George <ha************@boeing.comwrites:
>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: */.
Apparently, we share at least part of that. My own favorite killing
offense is '/* vi:set ts=anything: */' :)
On Tue, 19 Jun 2007 10:01:35 -0700, Xah Lee <xa*@xahlee.orgwrote:
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.
[Xah Lee <xa*@xahlee.org>]
|
| ----------------------------------------
| 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.
-Bjrn
[Xah Lee <xa*@xahlee.org>]
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.
-Bjrn
[Giorgos Keramidas <ke******@ceid.upatras.gr>]
|
| 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.
-Bjrn
Just so everyone's clear:
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
Kaldrenon <ka*******@gmail.comwrites:
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
On Jun 20, 9:28 am, David Kastrup <d...@gnu.orgwrote:
Kaldrenon <kaldre...@gmail.comwrites:
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.
[Kaldrenon <ka*******@gmail.com>]
| 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.
-Bjrn
Kaldrenon <ka*******@gmail.comwrites:
On Jun 20, 9:28 am, David Kastrup <d...@gnu.orgwrote:
>Kaldrenon <kaldre...@gmail.comwrites:
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.
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
On Jun 20, 1:59 am, "spamfilteracco...@gmail.com"
<spamfilteracco...@gmail.comwrote:
On Jun 19, 9:21 pm, Ed <iamfrac...@hotmail.comwrote:
Have you ever seen an, "Extractmethod," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its ownmethod, with the appropriatemethodinvocation left in
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.
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...
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.
On Jun 20, 8:52 am, Bjorn Borud <borud-n...@borud.nowrote:
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).
On Jun 20, 9:09 am, Kaldrenon <kaldre...@gmail.comwrote:
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. ;)
On Jun 17, 10:13 am, Xah Lee <x...@xahlee.orgwrote:
[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
Twisted <tw********@gmail.comwrites:
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
On Jun 20, 4:35 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
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.
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.
On Jun 20, 4:21 pm, BartlebyScrivener <bscrivene...@gmail.comwrote:
On Jun 17, 10:13 am, Xah Lee <x...@xahlee.orgwrote:
[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...
On Jun 20, 4:49 pm, Twisted <twisted...@gmail.comwrote:
On Jun 20, 4:35 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
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(exactURL escapes me; sorry).
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.
On Jun 20, 4:49 pm, Twisted <twisted...@gmail.comwrote:
On Jun 20, 4:35 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
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/027Int...sThatKill.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".
Twisted <tw********@gmail.comwrites:
On Jun 20, 4:49 pm, Twisted <twisted...@gmail.comwrote:
>On Jun 20, 4:35 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
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/027Int...sThatKill.html
Utterly unrelated to Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
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.
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".''
On Jun 20, 5:03 pm, Kaldrenon <kaldre...@gmail.comwrote:
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.
On Jun 20, 5:21 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
On Jun 20, 4:49 pm, Twisted <twisted...@gmail.comwrote:
On Jun 20, 4:35 pm, David Kastrup <d...@gnu.orgwrote:
Twisted <twisted...@gmail.comwrites:
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/027Int...sThatKill.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*. This thread has been closed and replies have been disabled. Please start a new discussion. |
