From: Dave Mielke <dave@mielke.ml.org>
To: blinux-list@redhat.com
Subject: Re: the glass tty model of human-computer interaction
Date: Mon, 14 Dec 1998 09:13:56 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.04.9812140813110.687-100000@dave.private.mielke.ml.org> (raw)
In-Reply-To: <199812140555.VAA29035@ohio.river.org>
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
next prev parent reply other threads:[~ UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
Richard Uhtenwoldt
` Ann K. Parsons
` wlestes
` Matthew Campbell
` Jude Dashiell
` Charles Hallenbeck
` Dave Mielke [this message]
` Lisa Carmelle
` Why I learned emacs was " wlestes
` Dave Mielke
` wlestes
` Moe Aitel
` Luke Davis
` Moe Aitel
` Luke Davis
` Lar Kaufman
` Why I learned emacs Richard Uhtenwoldt
` Dave Mielke
` Jude Dashiell
` the glass tty model of human-computer interaction wlestes
` Jude Dashiell
` Jude Dashiell
` James H. Cloos Jr.
` Mike Keithley
` Steve Holmes
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=Pine.LNX.4.04.9812140813110.687-100000@dave.private.mielke.ml.org \
--to=dave@mielke.ml.org \
--cc=blinux-list@redhat.com \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).