Re: Why I learned emacs was Re: the glass tty model of human-computer interaction

[Moe Aitel <aitelm@ase.com>]

Just a thought re the plea for three tones to indicate the status of the
three keyboard locks.  A simple hardware solution added to the keyboard
would have no effect on whatever software is in use, nor would it be
affected by that software.  We could tap onto the three LEDs and use 
each LED voltage to key a simple oscillator.  Then combine the three 
tones into a speaker to produce a chord.  Probably, the first addition 
to the accessory would be a volume control.  The whole kluge could be
much smaller than a pager, and free standing or built in.


wlestes@wlestes.uncg.edu wrote:
> 
> > 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
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe