From: wlestes@wlestes.uncg.edu
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 14:48:02 -0500 [thread overview]
Message-ID: <199812141948.OAA01960@wlestes.uncg.edu> (raw)
In-Reply-To: <Pine.LNX.4.04.9812141236400.687-100000@dave.private.mielke.ml.org>
> 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.
There is organization in emacs motion commands, for example. While the
organization may not be the "visual" layout of vi cursor motion
commands, the organization is there. Emacs came out of the MIT AI labs
from the mid to late 70s and I suspect much of its behavior is
explainable from that fact.
And emacs has quite good documentation so deducing key sequences is
rarely if ever called for. Also, you can write your own commands, if
you dont like the default ones.
> 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.
This makes sense--although, there exist packages to do vi style
editing in emacs--can you rewrite vi to do emacs style editing?
> 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.
But i learned emacs because i needed it for work. at the time, there
was no benefit for speech accessibility--i was running dos then. also,
i didnt learn elisp at the time, there are plenty of "cut and
paste"able pieces of code in the manuals to do many different kinds of
things. also, elisp is only a cost in the economists sense of that
word (if it werent elisp, it'd be something else). i used qedit (now
The Semware Editor), which had it's own extension language. it seems
that the most flexible editors--and that is what i want,
flexibility--come with extension languages.
Here's a case where switching modes on the fly actually helped:
I was writing some html/php3. I left out a brace from a nested if
statement and all that php3 was reporting was a syntax error at the
end of the document. so i put the buffer in awk-mode (php looks a lot
like C/awk) and had it reindent according to syntax. html mode is
essentially "text-mode" so that is why i had to switch modes. then the
indentation made it easy to find where the missing brace should have
been. and then I put the buffer back in html mode--to get the handy
short cuts for writing html.
> 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
I've heard of this kind of thing for DOS and friends, but not for
linux...anyone else?
Thanks for the thought provoking posts,
--will
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
` Lisa Carmelle
` Why I learned emacs was " wlestes
` Dave Mielke
` wlestes [this message]
` 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=199812141948.OAA01960@wlestes.uncg.edu \
--to=wlestes@wlestes.uncg.edu \
--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).