all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Xah Lee <xahlee@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: a look at the browser scene & emacs
Date: Wed, 25 Feb 2009 09:49:17 -0800 (PST)	[thread overview]
Message-ID: <45c61535-f0b1-426f-8fe2-42835a8b61a2@q9g2000yqc.googlegroups.com> (raw)
In-Reply-To: mailman.1758.1235567636.31690.help-gnu-emacs@gnu.org

On Feb 25, 5:13 am, Xiao-Yong Jin <xj2...@columbia.edu> wrote:
> the good old Emacs way

Let me give some examples of how many of the emacs's ways are
technically inferior. Some, to a degree that's outright stupid. The
reason, most emacs users, didn't see this, because over all emacs is
above all others, especially in the 1990s, and with that developed a
emacs cult. So, the perception becomes black & white, namely: emacs
way, or stupid way.

here's some example of emacs that are technically inferior.

-------------

• Why Emacs's Keyboard Shortcuts Are Painful
  http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html

Excerpt:

See also, a newsgroup post on “comp.emacs”. “Re: effective
emacs” (2008-06-01) by Daniel Weinreb. http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d.

    Xah wrote:
    «Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”,
“Ctrl
    +n”, “Ctrl+p”. The keys f, b, n, p are scattered around the
keyboard
    and are not under the home row.»

    Daniel wrote:
    That's true.  At the time Guy Steele put together the Emacs
default
    key mappings, many people in the target user community (about 20
    people at MIT!) were already using these key bindings.  It would
    have been hard to get the new Emacs bindings accepted by the
    community if they differed for such basic commands.  As you point
    out, anyone using Emacs can very easily change this based on
    their own ergonomic preferences.

Daniel is supposed to be the oldest emacs user.

-------------------

• The Modernization of Emacs
  http://xahlee.org/emacs/modernization.html

Excerpt:

«
Emacs's ways are technically superior. It should not change.

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 remember?)
    * Is it ergonomic? (Are most frequently used commands's keyboard
shortcuts easy to type? Are more frequently used commands have easier
to type shortcuts than less frequently used commands?)
    * Are most frequently used commands all have a keyboard shortcut?
    * Is the shortcut system somehow consistent and extensible?

Emacs's keyboard shortcuts system, is good only with respect to the
last item. 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, Ben Wing), and emacs's Ctrl and Meta
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 (ergonomic) 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, or the software
is used for repetitive, long durations of human-machine interaction
(such as data-entry, programing, writing). 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 issues to consider?

If we take careful consideration on creating a keyboard shortcut
system for emacs, it is not difficult to create a system that is
superior in some pure technical sense than the emacs's shortcut
system.

For some detail, see: Why Emacs's Keyboard Shortcuts Are Painful.

Aside from keyboard shortcuts system, other user interface aspects of
emacs 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 monochrome text-only 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 still takes a lot memory, and
opening multiple windows is slow and impractical.

Modern software interface (say, post 2000) usually uses one window per
file (or task), and or show tabs if multiple tasks are represented in
a single window. However, emacs's buffer system doesn't provide the
tabs visual clue. Compared to the modern standard of tabbed window,
emacs's buffer interface 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 more efficient
operation than a user interface based on modern software conventions.
(this can be tested by having 2 team of programmers roughly equally
experienced or skilled in using emacs. One team use Emacs with default
UI setup, the other use a emacs with modernized interface (such as
Mac's Aquamacs), then compare their efficiency in finishing a set of
coding tasks.)
»

----------------------------

the emacs cult induced black & white mentality is harmful. When in
online discussion, whenever some aspect of emacs is criticized that is
unique to emacs, the emacs users just see “Emacs Way” vs “Microsoft
way”, and therefore they think the only way is emacs way. It needn't
be that way. Certainly the emacs's system is great and made it last
over about 3 decades, but many aspects can adopt modern UI for the
better, while not taking away any advantage of emacs.

over the past 3 years i've spent a lot time on this and written a lot
detailed account. One latest one is about emacs's menus. See:

• Emacs's Menu Usability Problem
  http://xahlee.org/emacs/modernization_menu.html

This is about emacs's menu. You'll see that it is full of usability
problems. PS on this i sent to emacs bug report. So far no response.

  Xah
∑ http://xahlee.org/

      parent reply	other threads:[~2009-02-25 17:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-25  5:18 a look at the browser scene & emacs Xah Lee
2009-02-25 10:28 ` David Kastrup
2009-02-25 13:13   ` Xiao-Yong Jin
2009-02-25 22:26     ` Samuel Wales
2009-02-25 23:14       ` Xiao-Yong Jin
     [not found]   ` <mailman.1758.1235567636.31690.help-gnu-emacs@gnu.org>
2009-02-25 13:26     ` Richard Riley
2009-02-26  8:57       ` Miles Bader
2009-02-26  9:42         ` Xah Lee
     [not found]         ` <002094c7-f9fd-422e-a68f-67051e0c7483@w9g2000yqa.googlegroups.com>
2009-02-26  9:59           ` Tassilo Horn
     [not found]           ` <87k57dwmay.fsf@thinkpad.tsdh.de>
     [not found]             ` <go5qmt$a7e$1@news.sap-ag.de>
2009-02-26 11:23               ` Tassilo Horn
2009-02-28 15:48           ` Colin S. Miller
2009-02-28 18:12             ` Samuel Wales
2009-02-25 17:49     ` Xah Lee [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45c61535-f0b1-426f-8fe2-42835a8b61a2@q9g2000yqc.googlegroups.com \
    --to=xahlee@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.