From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Newsgroups: gmane.emacs.help Subject: Re: emacs-w3m question Date: Fri, 7 Nov 2008 09:43:23 -0800 (PST) Organization: http://groups.google.com Message-ID: <6bb9c6fc-d6a9-4b85-b1d3-3af180257690@i18g2000prf.googlegroups.com> References: <74160b46-e541-436a-a776-c8bd53d6cd55@o4g2000pra.googlegroups.com> <1f28a20e-0c9f-4478-a85c-27ae40ed7fc9@v16g2000prc.googlegroups.com> <4d476218-bd76-4d41-8a12-1428dfba9e9b@s9g2000prg.googlegroups.com> <107214be-5812-4519-bc29-a52f391f09a3@v13g2000pro.googlegroups.com> <2988b05b-9cc3-4407-a09f-cc334ad8f3c2@i24g2000prf.googlegroups.com> 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 1226083256 12880 80.91.229.12 (7 Nov 2008 18:40:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2008 18:40:56 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Nov 07 19:41:57 2008 connect(): Connection refused 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 1KyWHE-00010q-TA for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Nov 2008 19:41:49 +0100 Original-Received: from localhost ([127.0.0.1]:44316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyWG7-0000qg-H1 for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Nov 2008 13:40:39 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!i18g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help,comp.emacs Original-Lines: 141 Original-NNTP-Posting-Host: 24.6.185.159 Original-X-Trace: posting.google.com 1226079804 2551 127.0.0.1 (7 Nov 2008 17:43:24 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Fri, 7 Nov 2008 17:43:24 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i18g2000prf.googlegroups.com; posting-host=24.6.185.159; 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.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.22, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:164228 comp.emacs:97327 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:59562 Archived-At: Alan Mackenzie wrote: > > > I think, by his description, he does. "Touch type" meaning "not > > > having to look at the keyboard to type". > > using 6 fingers instead 10 is not considered touch typing. > > "Is not considered" :-). I don't think we should be so concerned to > divide people (or even things) into categories. Pluto is just the same > lump of rock and ice it always was, whether we call it a planet or not. Dear Alan moron, nor is this about skin color. If you are a moron, dressing well doesn't change the fact, > I don't know any Mac Emacs users, so I couldn't comment on its > popularity. the question is not about whether you know or don't know mac emacs users. It's about you lacking requisite knowledge yet insist on your opinion about the subject. > But we've had this discussion several times. Modern isn't necessarily > better. Modern is easier for newbies familiar with other programs to > learn, but there's no evidence that, once learnt, it's any better than > the classic Emacs UI. Do you address this matter anywhere in your online > essays? My own experience is that Emacs's classic UI is much better. > One reason to believe Emacs UI should be superior is that it was > developed by the people who use it, for their own use. yes it's addressed in my essay, under the FAQ section. In fact, this has been addressed so many times, just about every few months. It's quite amazing that some thoughts just never registers in tech geeker' brain. See: The Modernization of Emacs http://xahlee.org/emacs/modernization.html The FAQ section starting near the middle of page. Here's a excerpt of the section. Q: 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=E2=86=97, Jamie Zawinski=E2=86=97, Ben Wing=E2=86=97), 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=E2=86=97 (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 certified 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.) Note: we are not disputing the general power, flexibility, and qualities of emacs. Emacs, with a powerful embedded language lisp, and consequently embodies many software applications other than text editing (email, ftp, dired, calc, ...etc), has induced certain system of user interface that is all consistent and unique in comparison to modern software applications. We do not advocate that this is bad. Specifically, we only propose a very few trivial items for interface or documentation changes as listed in this article. Most are simply turning on some features by feault and or changing some terminologies in the documentation. They have no bearings on how emacs operate in general. Xah =E2=88=91 http://xahlee.org/ =E2=98=84