public inbox for blinux-list@redhat.com
 help / color / mirror / Atom feed
From: Dave Mielke <dave@mielke.ml.org>
To: blinux-list@redhat.com
Subject: Re: Why I learned emacs was Re: the glass tty model of human-computer interaction
Date: Mon, 14 Dec 1998 13:15:41 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.04.9812141236400.687-100000@dave.private.mielke.ml.org> (raw)
In-Reply-To: <199812141550.KAA01739@wlestes.uncg.edu>

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


  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
   ` Lisa Carmelle
   ` Why I learned emacs was " wlestes
     ` Dave Mielke [this message]
       ` 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.9812141236400.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).