the glass tty model of human-computer interaction

the glass tty model of human-computer interaction

[Richard Uhtenwoldt]

I'm not blind, just interested in making my software blind friendly.

In the Seventies before the personal computer became popular a lot of
interaction with computers occured via the so-called hardcopy terminal,
like the DECwriter and the Teletype Model 33 before that, which is
essentially a keyboard connected to a printer.  at the end of the session,
you have a long piece of paper that is essentially a transcript of
everything you wrote and everything the computer wrote in reply.

there was also the dumb terminal, also called the glass tty, which differed
from a vt100 in that its cursor was not addressible.  the only way the
computer could update a glass tty was by writing a line of text at the
bottom of the screen and having whatever was on the screen scroll up one
line.  cursor-addressible terminals were also called smart terminals.  now
we may laugh at the idea, but in the Seventies a smart terminal cost
thousands of dollars, hence the market for dumb terminals as a lower-cost
solution.

you could not use vi or Emacs on a hardcopy terminal or a glass tty.  what
you used instead was what I will call a "line editor" which had commands
like "delete the next 5 lines" and "print the next 5 lines".  the Unix
command "ed" and I think also "ex" are line editors.  sighted users came to
prefer so-called visual editors like vi and Emacs in which most of the
display is devoted to an alway-up-to-date view of the thing being edited.
it occurs to me, tho, that if I were a blind user using text-to-speech
hardware or a braille output device, I would prefer a line editor.  but the
Linux Access Howto mentions Emacspeak but does not mention any line
editors.

so, if you are blind and have used a line editor, please tell me whether
you prefer line editors or visual editors.

Re: the glass tty model of human-computer interaction

[Ann K. Parsons]

Hi all,

IMHO, it depends on what you're doing.  If I'm going to write a long
document, like a report, then a full screen editor is what I want because
you can move about easier within it. You can go to certain pages instead of
lines and so on.

If, on the other hand, I'm writing something short, or if I am programming
in MOO, or looking for errors in a program in MOO that I have written, then
a line editor is much easier to use.

I guess what I am saying is that IMHO, it depends on why you're using the
editor.

Ann P.
At 09:55 PM 12/13/98 -0800, Richard Uhtenwoldt wrote:
>I'm not blind, just interested in making my software blind friendly.
>
>In the Seventies before the personal computer became popular a lot of
>interaction with computers occured via the so-called hardcopy terminal,
>like the DECwriter and the Teletype Model 33 before that, which is
>essentially a keyboard connected to a printer.  at the end of the session,
>you have a long piece of paper that is essentially a transcript of
>everything you wrote and everything the computer wrote in reply.
>
>there was also the dumb terminal, also called the glass tty, which differed
>from a vt100 in that its cursor was not addressible.  the only way the
>computer could update a glass tty was by writing a line of text at the
>bottom of the screen and having whatever was on the screen scroll up one
>line.  cursor-addressible terminals were also called smart terminals.  now
>we may laugh at the idea, but in the Seventies a smart terminal cost
>thousands of dollars, hence the market for dumb terminals as a lower-cost
>solution.
>
>you could not use vi or Emacs on a hardcopy terminal or a glass tty.  what
>you used instead was what I will call a "line editor" which had commands
>like "delete the next 5 lines" and "print the next 5 lines".  the Unix
>command "ed" and I think also "ex" are line editors.  sighted users came to
>prefer so-called visual editors like vi and Emacs in which most of the
>display is devoted to an alway-up-to-date view of the thing being edited.
>it occurs to me, tho, that if I were a blind user using text-to-speech
>hardware or a braille output device, I would prefer a line editor.  but the
>Linux Access Howto mentions Emacspeak but does not mention any line
>editors.
>
>so, if you are blind and have used a line editor, please tell me whether
>you prefer line editors or visual editors.
>
>
>---
>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
>
>

Re: the glass tty model of human-computer interaction

[wlestes]

Note that Ann's response is essentially the same as one that might be
given by a sighted person. The real issue is that *whatever* the
interface, as a blind user, I, at least, want a way to access
it. There are some tasks for which command line programs are ideal,
and others for which visual/graphical interfaces are ideal. As Ann
says, some tasks are better suited for line editors and others less so.

> IMHO, it depends on what you're doing.  If I'm going to write a long
> document, like a report, then a full screen editor is what I want because
> you can move about easier within it. You can go to certain pages instead of
> lines and so on.
> 
> If, on the other hand, I'm writing something short, or if I am programming
> in MOO, or looking for errors in a program in MOO that I have written, then
> a line editor is much easier to use.
> 
> I guess what I am saying is that IMHO, it depends on why you're using the
> editor.
> 
> Ann P.

Re: the glass tty model of human-computer interaction

[Matthew Campbell]

Since you mention Ann's response to the question of line editors vs. visual
editors, I think it would be a good idea if I explain what MOO is, since
she referred to it a couple times. (She and I are good friends, BTW.) A MOO
is a text-based virtual reality (VR) in which you can talk to other users,
move about, look at rooms and objects, create your own objects, and program
them.  The MOO includes a line editor which can be used for writing text or
code within the MOO.  This is what she was talking about, just so you know.

Matt Campbell
Director of Technology, GrassRoots MOO
http://health.acor.org/grassroots/

Re: the glass tty model of human-computer interaction

[Jude Dashiell]

With ex, it's possible to find any place in a file quickly provided you
remember you don't have to use line numbers for your search.
:/dog <cr>
typed at the top of a file would take you to the first line that contains
dog.


------------------------------------------------------------------------

jude <jdashiel@clark.net>

Re: the glass tty model of human-computer interaction

[Charles Hallenbeck]

I have had a lot of experience with line editors dating from the late
1960s and as I think about it, it has been a very long time since I have
used one. I presently use a standard word processor for writing and
editing documents (I hate to admit it but I am a WordStar freak), and a
full screen "visual editor" (Brief by Borland and Underware) for program
preparation and editing.
I think the reason line editors and the dumb terminal went together so
well was the fact that one had to use the same key presses for editor
commands as for data entry. That meant there needed to be a convention for
switching back and forth between "edit mode" and "command mode". Even
though as a blind user I perhaps cannot appreciate the expanse of the
whole screen at once, there is an enormous convenience in not having to
think constantly about this distinction between the two "modes". Thus
while VI is a visual editor, it retains the problem of "edit mode" and
"command mode" and therefore resembles an older style line editor more
closely than a modern word processor.
Word processors and single-mode editors are clearly more convenient than
dual-mode editors, whether line or full screen oriented.
Thanks for your very interesting question.
BTW -- our screen review software, provox, has two modes of operation
which we call "standard mode" and "enhanced mode." In the former, one
needs to switch back and forth between using the keyboard for
communicating with the application, or using it for reviewing the screen.
The enhanced mode sets aside the numeric keypad for the exclusive use of
the speech software, so that in effect it is always in review mode, while
the rest of the keyboard is always in the active data entry mode. There
are in effect two cursors, one controlled by the running application and
one controlled by the user for screen review purposes. I had not thought
before about the similarity of this modality to the question of editor
design, but the similarity is striking.
 

Chuck -- Second Sight Software
Now using Linux and PINE

Re: the glass tty model of human-computer interaction

[Dave Mielke]

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

Re: the glass tty model of human-computer interaction

[Lisa Carmelle]

Richard,
	I am wondering about your distinction between line editors and
visual editors.  I prefer full screen editors such as the edit program
which comes with WP 6.0 in DOS.  I dislike line editors generally.   I
rarely use anything but word processing nowadays even for short batch file
writing and so on.

	Lisa

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

[wlestes]

A couple years ago, I used whatever word processor and text editor I
could get my hands on. Sometimes this was eve on VMS, WordPerfect on
DOS, qedit on DOS. Then because I was in a group project in a computer
architecture class and because the campus runs some unix boxes and
because the djgpp environment is free software, I downloaded
emacs--all i think 7 floppies worth of binaries and elisp sources--and
took the plunge. I was using jaws on dos and telnetting into the unix
machines at school and DOS with a screenreader at home to access
emacs. After about an hour or two of reading the on line tutorial, I
got the hang of emacs, at least enough to function. I had no trouble
understanding the logic of emacs commands or figuring out how to do
what I wanted to do. I *stayed* with emacs because it was more
powerful than anything else I was using at the time. I think it was
the compilation from inside emacs that really proved the point.

> 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.

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?

> 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.

true enough, but for me the logic of switching to linux was more like
this:

djgpp is great, but it aint the "real" thing.
emacs has the best support on linux.
I already know emacs.

and now that I have linux natively support (well, ok, we have to
overlook the dec speech synthesizer), I can develop software that *I*
want. *smile*

> since I believe that one should always use the best tool for the job at hand, I

amen to this line. whatever our preferences, this is the real
consideration.

> 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.

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.

> 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

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...

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

[Dave Mielke]

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

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

[wlestes]

> 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

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

[Moe Aitel]

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

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

[Luke Davis]

I know this response is a bit late...:)

Sounds easy enough to do; I might give it a shot when I get a few spare
hours.
How are you thinking: reading the LEDs with PE cells, or pulling directly
from the keyboard cable through an interceptor?  The only thing with that
is you might have to regen the signal, which would make it a bit more
complex than it needed to be.

On Tue, 15 Dec 1998, Moe Aitel wrote:

> 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
> 
> ---
> 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
> 
> 

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

[Moe Aitel]

Luke

I am a bit more simple minded than that.  I am thinking of opening the 
keyboard (usually 2 screws) and soldering wires to the "hot" side of the
three LEDs.  

We will need three buffers to isolate us, so we do not disturb the LED
function -- they could be almost any ten cent transistors.  The signals
can then switch three oscillators whose outputs are mixed to send the
one, two, or three tone chord through another ten cent transistor to
almost any kind of speaker, like a pc speaker or a tiny (tinny?) pietzo
speaker.  

The whole kluge could be assembled for less than a few dollars worth of
parts.  Most likely, the job will require a sighted technician
(hobbyist?), but I do 
not want to underestimate anyone.   

So far, the suggestion was/is an impulsive response to Will's wish list,
and 
I have not actually designed and built it -- yet.   If you and others
would benefit from it, I would be willing to design it and build up a
proto (to make sure it really works) and make the design available,
under the GNU copyleft or equivalent.

Moe
----------------
Luke Davis wrote:
> I know this response is a bit late...:)
> Sounds easy enough to do; I might give it a shot when I get a few spare
> hours.
> How are you thinking: reading the LEDs with PE cells, or pulling directly
> from the keyboard cable through an interceptor?  The only thing with that
> is you might have to regen the signal, which would make it a bit more
> complex than it needed to be.
-------------------- 
> On Tue, 15 Dec 1998, Moe Aitel wrote:
> > 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:
> > > > 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). > > > --will

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

[Luke Davis]

Yes, that would work just as well...
Only one real problem with that: everyone has to build their own.

90 or more % of the people who need it aren't going to want to do it...

But you give me an idea; I'll get with you privately...

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

[Lar Kaufman]

Don't forget that emacs has a fourth keyboard lock binding, the Escape key.
So you can map functions to Esc-<anykey> where chorded input is made difficult
for a physically impaired user.

 -lar
"This ain't no party, this ain't no disco, this ain't no fooling around. No
time for dancing or lovey-dovey, I ain't got time for that now. I sent a
message through the receiver, hope to get an answer someday. Why stay in
college? Why go to night school? Thought I'd be different this time." -D. Byrne

Re: Why I learned emacs

[Richard Uhtenwoldt]

Dave Mielke writes:

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. (end of my quoting of Dave Mielke.)

Hi, Dave.  As a long-time Emacs user, I also think Emacs keymaps could
stand more orthogonality.

Dave Mielke writes:

I occasionally even have one hand on the keyboard and the other one on the
braille 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. (end of quote.)

I use the so-called sticky-keys feature of the Linux console, which means
that to generate a control-c, I press and release a control key and then
press and release the c key.  I use it because holding keys down 
tends to cause more pain in my wrists than tapping keys.

X also features sticky keys, but I would think that if
you are blind, then you do not use X but rather you use the Linux console
for almost all of your Linux work.

Anyway, upon request I am willing to post instructions on configuring the
Linux console so that the modifier keys become sticky.  Alternatively,
follow the instructions after the second occurence of the word "sticky" in
the Keyboard-and-Console-HOWTO.

Finally, Dave Mielke writes:

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).
(end of quote.)

I have wanted something like this myself, and like I said, I am not blind.
Dave, please confirm that you want this for Linux running in text mode
rather than under X.

Re: Why I learned emacs

[Dave Mielke]

On Mon, 14 Dec 1998, Richard Uhtenwoldt wrote:
>X also features sticky keys, but I would think that if
>you are blind, then you do not use X but rather you use the Linux console
>for almost all of your Linux work.

Yes, you are correct.

>Dave, please confirm that you want this for Linux running in text mode
>rather than under X.

Yes, again, you are correct. I use text mode and BRLTTY.

-- 
Dave Mielke               | 856 Grenon Avenue | I believe that the Bible is the
Phone: 1-613-726-0014     | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave@mielke.ml.org | Canada  K2B 6G3   | if you're concerned about Hell.

Re: Why I learned emacs

[Jude Dashiell]

it is after all possible to rewrite key bindings.  There's a wordperfect
set available for
emacs already.


------------------------------------------------------------------------

jude <jdashiel@clark.net>

Re: the glass tty model of human-computer interaction

[wlestes]

> I'm not blind, just interested in making my software blind friendly.

In general, I have noticed that "good Unix programs" are best for me
as a blind user.

> it occurs to me, tho, that if I were a blind user using text-to-speech
> hardware or a braille output device, I would prefer a line editor.  but the
> Linux Access Howto mentions Emacspeak but does not mention any line
> editors.
> 
> so, if you are blind and have used a line editor, please tell me whether
> you prefer line editors or visual editors.

My own preference is for visual editors. I think this is because
visual editors reflect more naturally the structure (lines, pages,
paragraphs, etc.) of files and line editors typically do not. So this
is not inherent in line editors, just a historical development.

--will

Re: the glass tty model of human-computer interaction

[Jude Dashiell]

I'm totally blind and yes I prefer a line editor to visual editors.
One good hybrid is jove.  Doesn't appear so until you find out how to turn
the line
numbers on to the left of what you're editing and it's possible to use
line number addresses in
command specifications.  Understand, I use edlin on a regular basis when
using dos so
line editors work quite well for me.  Another somehwat defective CP/M line
editor I think from sig/m was
secretry.com.  It was a hybrid like jove too but had lots more stuff on
menus.


------------------------------------------------------------------------

jude <jdashiel@clark.net>

Re: the glass tty model of human-computer interaction

[Jude Dashiell]

Actually, forgot to mention that vi is a subset of ex.  Those sighted
users who gave up
ex in favor of vi and they know who they are, gave up the extra power
having the
whole command set at their disposal provided.  


------------------------------------------------------------------------

jude <jdashiel@clark.net>

Re: the glass tty model of human-computer interaction

[James H. Cloos Jr.]

WRT line editors vs visual ones, note that nvi and vim at least, and
perhaps the other vi clones, support line mode.  In the case of nvi,
and vim, if called ex they will operate a la the original ex.

As far as I know, nvi's `colon mode' supports all ex commands.

(As a hard core (sighted) emacs user, when I first was forced to use
vi, I insisted in running it as ex in protest of the `insert mode' vs.
`visual mode' distinction. :)

-JimC
-- 
James H. Cloos, Jr.       <http://www.jhcloos.com/cloos/pgp_public_key.txt>
<cloos@jhcloos.com>      E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

Re: the glass tty model of human-computer interaction

[Mike Keithley]

>so, if you are blind and have used a line editor, please tell me whether
>you prefer line editors or visual editors.
>
I've used line editors on Compuserve and HPUX in the days when I was
using the VersaBraille.  I never did like them because I always got
lost.  Vi is much nicer through a VT100 terminal, even working through a
slow derial connection.

-- 
Mike Keithley

Re: the glass tty model of human-computer interaction

[Steve Holmes]

I've always prefered using full screen or "visual" editors.  I always
found line editors to be too okward and clumbsy for me.

My favorite editor of all time is the semware editor for DOS and
programmers file editor for windows a close second.  The linux or unix
full screen editors such as VI or emacs, have navigation commands far
less intuitive than their DOS / windows counterparts.

On Sun, 27 Dec 1998 21:37:12 -0800, mikek24@concentric.net (Mike
Keithley) wrote:

>>so, if you are blind and have used a line editor, please tell me whether
>>you prefer line editors or visual editors.
>>
>I've used line editors on Compuserve and HPUX in the days when I was
>using the VersaBraille.  I never did like them because I always got
>lost.  Vi is much nicer through a VT100 terminal, even working through a
>slow derial connection.

--
<Steve> Holmes
Tempe, Arizona  USA