From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Lee Newsgroups: gmane.emacs.help Subject: Re: a look at the browser scene & emacs Date: Wed, 25 Feb 2009 09:49:17 -0800 (PST) Organization: http://groups.google.com Message-ID: <45c61535-f0b1-426f-8fe2-42835a8b61a2@q9g2000yqc.googlegroups.com> References: <8358de80-5198-41e5-b4a2-04e681d359d1@p20g2000yqi.googlegroups.com> <86wsbeajz6.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1235637341 29777 80.91.229.12 (26 Feb 2009 08:35:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2009 08:35:41 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Feb 26 09:36:55 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lcbjc-0002zA-TR for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Feb 2009 09:36:49 +0100 Original-Received: from localhost ([127.0.0.1]:39542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcbiI-0006J4-59 for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Feb 2009 03:35:26 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!q9g2000yqc.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help,comp.emacs Original-Lines: 164 Original-NNTP-Posting-Host: 24.6.175.142 Original-X-Trace: posting.google.com 1235584157 25456 127.0.0.1 (25 Feb 2009 17:49:17 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Wed, 25 Feb 2009 17:49:17 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: q9g2000yqc.googlegroups.com; posting-host=24.6.175.142; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:167070 comp.emacs:97860 X-Mailman-Approved-At: Thu, 26 Feb 2009 03:35:03 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:62389 Archived-At: On Feb 25, 5:13 am, Xiao-Yong Jin 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. ------------- =E2=80=A2 Why Emacs's Keyboard Shortcuts Are Painful http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html Excerpt: See also, a newsgroup post on =E2=80=9Ccomp.emacs=E2=80=9D. =E2=80=9CRe: ef= fective emacs=E2=80=9D (2008-06-01) by Daniel Weinreb. http://groups.google.com/gro= up/comp.emacs/msg/0342e0bc1aa05c0d. Xah wrote: =C2=ABEmacs's default cursor moving shortcuts are =E2=80=9CCtrl+f=E2=80= =9D, =E2=80=9CCtrl+b=E2=80=9D, =E2=80=9CCtrl +n=E2=80=9D, =E2=80=9CCtrl+p=E2=80=9D. The keys f, b, n, p are scattere= d around the keyboard and are not under the home row.=C2=BB 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. ------------------- =E2=80=A2 The Modernization of Emacs http://xahlee.org/emacs/modernization.html Excerpt: =C2=AB 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 =E2=80=9Cwindows= =E2=80=9D is not practically available, and the emacs's method of using the screen (the monochrome text-only monitor) for presenting multiple tasks (=E2=80=9Cbuffers=E2=80=9D) is actually a very advanced user interfac= e 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.) =C2=BB ---------------------------- 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 =E2=80=9CEmacs Way=E2=80=9D vs = =E2=80=9CMicrosoft way=E2=80=9D, 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: =E2=80=A2 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 =E2=88=91 http://xahlee.org/ =E2=98=84