From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 31221 invoked from network); 14 Dec 1998 18:56:34 -0000 Received: from mail.redhat.com (199.183.24.239) by lists.redhat.com with SMTP; 14 Dec 1998 18:56:34 -0000 Received: from wlestes.uncg.edu (wlestes.uncg.edu [152.13.173.71]) by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA22954 for ; Mon, 14 Dec 1998 13:47:57 -0500 From: wlestes@wlestes.uncg.edu Received: (from wlestes@localhost) by wlestes.uncg.edu (8.8.7/8.8.7) id OAA01960; Mon, 14 Dec 1998 14:48:02 -0500 Date: Mon, 14 Dec 1998 14:48:02 -0500 Message-Id: <199812141948.OAA01960@wlestes.uncg.edu> X-Authentication-Warning: wlestes.uncg.edu: wlestes set sender to wlestes@wlestes.uncg.edu using -f To: blinux-list@redhat.com Subject: Re: Why I learned emacs was Re: the glass tty model of human-computer interaction References: List-Id: > 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