From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 31431 invoked from network); 14 Dec 1998 14:23:02 -0000 Received: from mail.redhat.com (199.183.24.239) by lists.redhat.com with SMTP; 14 Dec 1998 14:23:02 -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 JAA08499 for ; Mon, 14 Dec 1998 09:14:31 -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 JAA17084 for ; Mon, 14 Dec 1998 09:14:00 -0500 Received: from localhost (dave@localhost) by dave.private.mielke.ml.org (8.8.7/8.8.7) with ESMTP id JAA12613 for ; Mon, 14 Dec 1998 09:13:57 -0500 X-Authentication-Warning: dave.private.mielke.ml.org: dave owned process doing -bs Date: Mon, 14 Dec 1998 09:13:56 -0500 (EST) From: Dave Mielke To: blinux-list@redhat.com Subject: Re: the glass tty model of human-computer interaction In-Reply-To: <199812140555.VAA29035@ohio.river.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: On Sun, 13 Dec 1998, Richard Uhtenwoldt wrote: >so, if you are blind and have used a line editor, please tell me whether >you prefer line editors or visual editors. I am a blind person who has relied on a hardcopy terminal (and an optacon to read it) until just under a year ago. I have now switched to a braille display. In my hardcopy terminal days I was an avid use of command-line editors. I found ED to be rather cryptic, so I solved the problem years ago by writing my own command-line editor. This not only gave me friendly and easy to use/remember commands, but also gave me the flexibility of being able to add new functionality every time I needed it, so that, in the end, it became an incredibly powerful tool. Now, in my braille display days, I much prefer visual editing. The reason for the switch is that the braille display, which presents me a full line at a time, enables me to get instant feedback with respect to what I am doing. I can use one hand to type on the keyboard, and, with one finger of my other hand I can immediately determine the success or failure of the editing operation. I can also place one finger on the leftmost character of, say, an IF statement of a program, and use the cursor up/down keys in order to determine the correct indentation of its body and termination token. I, personally, do not like the EMACS style of editor, although, due to its support of speech output, I can readily understand its attractiveness to most blind people. One of the problems with EMACS is that many of its functions do a lot of unpredictable things, which, to my mind, makes it very difficult for a blind person to truly be sure of what has happened in response to a given command. EMACS relies on its user having a full view of the screen at all times, which, whether braille or speech is being used, is not a presentation mode which lends itself to easy use by a blind person. Another problem with EMACS is that its key sequences have not been designed with orthogonality in mind, so that one must rely on intensive research, rather than on intuition, when trying to do something new. The draw to EMACS for those who rely on speech is that it has the best interactive speech support to date, which, even now, is still undergoing further development. EMACS also enables its user to start any host command from within it, which immediately makes all host commands speech-usable, without the user even having to learn anything new. These very powerful assets will have the predictable effect of causing the user to gladly put up with EMACS' inconviences, because a blind person is always having to accept what is less than perfect simply because significantly greater freedom is worth the payment of that small price. Since I use a full-line braille display, and not speech, I am not quite as limited. I, therefore, have found that a VI-like editor is much more "blind-friendly". First, its commands are orthogonally designed and macro-like, which means that I can do a lot of very predictable yet very powerful operations with very few key strokes. Second, its commands never have an effect beyond the scope of what the user has explicitly specified, which means that unpredictable things never happen elsewhere on the screen. I have found VI itself to be somewhat limiting, and have personally settled on VIM as my favourite editor. VIM offers a number of things over VI which have formerly caused VI users to switch to EMACS, but with a VI-like approach. Some of these features include extensive on-line help, block-mode editing (character-, line-, or rectangle-based), and the ability to edit several files simultaneously in different editing windows. If I were only allowed to use one editor for everything, then VIM would be my choice. Since, however, I am allowed to have as many favourites as I want, and since I believe that one should always use the best tool for the job at hand, I also like PICO. I use VIM for writing/fixing software, editing data files, etc., i.e. for editing anything that is of a line-oriented nature. I use PICO, on the other hand, for editing anything that is of a text-oriented nature, e.g. this reply. 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. I shall conclude these thoughts by declaring my gripe with all of the visual editors which I have encountered so far ... They are all case-sensitive! I often press a key, thinking that my uppercase lock is off, and then, to my dismay, discover that an entirely wrong, and occasionally irrecoverable, thing has happened. I am still in search of either an easy way to know in advance what the state of my uppercase lock key is, or a good visual editor which is not case-sensitive. -- Dave Mielke | 856 Grenon Avenue Phone: 1-613-726-0014 | Ottawa, Ontario EMail: dave@mielke.ml.org | Canada K2B 6G3