From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 26958 invoked from network); 14 Dec 1998 18:24:51 -0000 Received: from mail.redhat.com (199.183.24.239) by lists.redhat.com with SMTP; 14 Dec 1998 18:24:51 -0000 Received: from mielke.ml.org (cpu2311.adsl.bellglobal.com [207.236.16.34]) by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA21077 for ; Mon, 14 Dec 1998 13:16:15 -0500 Received: from dave.private.mielke.ml.org (dave@dave.private.mielke.ml.org [192.168.0.2]) by mielke.ml.org (8.8.7/8.8.7) with ESMTP id NAA18108 for ; Mon, 14 Dec 1998 13:15:44 -0500 Received: from localhost (dave@localhost) by dave.private.mielke.ml.org (8.8.7/8.8.7) with ESMTP id NAA14003 for ; Mon, 14 Dec 1998 13:15:42 -0500 X-Authentication-Warning: dave.private.mielke.ml.org: dave owned process doing -bs Date: Mon, 14 Dec 1998 13:15:41 -0500 (EST) From: Dave Mielke To: blinux-list@redhat.com Subject: Re: Why I learned emacs was Re: the glass tty model of human-computer interaction In-Reply-To: <199812141550.KAA01739@wlestes.uncg.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: On Mon, 14 Dec 1998 wlestes@wlestes.uncg.edu wrote: >orthogonality with respect to what? I dont follow you here. I am >"functionally" blind with respect to (most things including) computing >and I have no trouble conceptualizing what emacs is doing. Did you >have something in mind with respect to your comment that emacs >requires a full knowledge of the layout of the screen? No. It is fairly easy to conceptualize what EMACS does with the screen. I was referring to the rather haphazard way in which its command sequences have been defined. The fact that I may happen to know the sequence to get some given functionality does not guarantee that I can deduce a sequence which will yield similar functionality. The VI commands, on the other hand, are more organized. One example is that there are a common set of motion controls which apply to all of the commands which require them. Another is the very easy-to-remember rule that lowercase word-oriented motion controls refer to alphanumeric words whereas uppercase ones refer to blank-delimited words. Someone else made a comment about VI being a bit more difficult to use because of its bimodal presentation, i.e. it has a data input mode which is distinctly different from its command mode. Speech users would most likely prefer the unimodal presentation of EMACS because they would tend to keep both of their hands on the keyboard at all times. I, on the other hand, being a braille display user, am constantly moving my hands from the keyboard to the display and back again. I occasionally even have one hand on the keyboard and the other one on the display. When doing this latter bit of dexterity, it's a bit difficult to hold down the control key (and, perhaps, in addition, the ALT key) and a letter all simultaneously with one hand. I, therefore, prefer the VI style of strictly single key operation; while VI does make use of the shift key, none of its character editing functions use uppercase letters. The bimodal nature of VI (or, in my case, VIM) is a very, very small price for me to pay given the vastly increased freedom I get from the use of a braille display. >> PICO offers automatic line wrapping and paragraph rejustification, >> which are essential when editing textual data. VIM offers both of these >> functions as well, but in a more difficult to use way. > >but in emacs, these modes are both present with several ways of >switching between them. It can be done automatically with a few lines >of elisp in the init file or manually by typing some commands. This is an example of your willingness to pay a small price with respect to EMACS' clumsiness because I'm sure that you gain great benefits from its speech-friendliness. I don't want to learn ELISP just so that I can mess around with my editing environment. I also don't want to type a few cryptic commands every time I want to switch modes. I just want to use an editor which will do the right thing. Since I've never found a case in which I need to switch modes on the fly, I just invoke the right editor for the job that needs to be done. >One could write a mode in emacs to be case insensitive when issuing >editing commands. Probably start with one of the vi modes as a base... I think that my preference would be to have some sort of generic keyboard support which would present three persistent tones, each at a distinctly different pitch, for each of the three locks (upercase, numeric, scroll). This approach would make it much easier to predictably use all tools, most of which are case-sensitive, rather than just kludge something together for one of them. It becomes a bit of a farce, after all, if all tool developers must keep in mind at all times all of the unique needs of each special interest group. I am not a believer in coming up with solutions that only deal with individual problems. I think that one's time is far better spent coming up with general solutions which resolve a host of problems at once. -- Dave Mielke | 856 Grenon Avenue Phone: 1-613-726-0014 | Ottawa, Ontario EMail: dave@mielke.ml.org | Canada K2B 6G3