[Prev][Next][Index][Thread][Search]

Emacspeak 3.70


Hi Sam,

Thanks for the detailed message, and I'm really glad things are beginning to
work for you with eterm even though there are still problems.

I'll  answer your questions by interspersing my responses through the message;
you've got so many questions here that otherwise I'll miss some of them.

First off though, I spent time this  weekend hacking the eterm code
and fixed a few bugs in the implementation. I also have windowing support
working well, and judicious use of this may help you in a lot of cases.

Here is what the windowing support looks like:

You take the eterm pointer to one corner of the conceptual window, and set
eterm mark there. Then you move to the opposite corner ie bottom right of the
conceptual window, and then invoke the window definition command (bound to c-t
c-w).
This will prompt you for a window number, and also ask if you would like the
window to stretch to the right or left.

You can hear the contents of a defined window with one command bound to c-t
ret which prompts for a window-id.

Now for answering your questions:

Sam Hartman writes:
 > 	Ok, I've been playing with Emacspeak today, and it's really
 > starting to work well.  (I finally got around to committing the great
 > sin of building tclX for my desktop, and the Gnus support is really
 > neat.  )  Also, the changes to Eterm appear to be working well, and
 > make it quite usable.
So how did you use emacspeak without having tclx till now?


 
 >For example, I tend to read my mail inside an
 > Emacs running under Eterm, because I'm currently using mh-e and since
 > there is no customized mode for it currently, it actually works fairly
 > well to just use Eterm.
Writing an emacspeak extension to mh-e should be straightforward, never did it
because I don't use mh. Want to write it?

 
 > It certainly works well enough to handle
 > remote compiles and editing, although I am beginning to get used to
 > the advantages of locally editing files in the Emacspeak Emacs.
 And believe me, the more you do this, the less you will want to use emacspeak
 as a vanila screenreader under eterm.
 For instance, check out voice locking and the other goodies under cc-mode
 
 
 > 
 > 	I've noticed a few minor things.  I don't know if the first
 > two are Dectalk bugs or Emacspeak bugs--there was some minor confusion
 > about the firmware upgrade, so I'm still running a hacked dtk-exp with
 > the old firmware.
Could you resolve the "firmware upgrade confusion" first? What exactly
happened?
It's hard to remember the set of bugs the old firmware had, given that the new
firmware has other exotic bugs of its own.

 > 
 > * If the Dectalk is given a long list of text (say a PGP signature, or
 > a list of words, possibly not separated by spaces), it fails rather
 > impressivly--clicking rapidlythrough some of the text.
An emacspeak problem/bug.
I try really hard to send the dectalk a clause at a time to get good
intonation; and things like pgp signatures end going through to the dectalk in
one fell swoop causing the problem. It's surprising though that you say it
"clicks" through the text; this indicates that for some reason the dectalk is
going into phonetic mode, and emacspeak does take care to avoid this.
The only problem things like pgp sigs should cause is that the dectalk wont
shut up immediately as it otherwise does, simple solution is to power cycle
the dectalk and restart the dtk driver with c-e c-s.

 
 > 
 > * If the first letter on a line is capitalized, it isn't beeped.
 This is an emacspeak bug. Actually, the way this feature is implemented is
 rather pokey and the bug is hard to fix. 
 > 
 > * I think C-e c should indicate whether or not the character is
 > capitalized even if capitalization mode is off.  (It doesn't do this
 > now, even if capitalization mode is on).
 I agree with the above. I was just too lazy to implement it that way; will do
 it if I can muster up the energy.
 
 > 
 > * Feature request: a command to tell what column you are in. C-x= does
 > this, but it's at the end of the message line.  (This is mostly for
 > indentation in programs.)
 I'll throw this in.  Have you tried out the "audio indentation"? It's
 marginally useful. (I always turn it off)
 
 > 
 > * What should happen with blinking parenthesis? (I am aware of C-e),
 > but even after pressing it, nothing happens when I close parens.
 c-e ) causes emacspeak to use a different blink-paren function that speaks
 the relevant portion of the text to indicate which paren matched. Note
 however that this will have no effect whatsoever under eterm. There, the only
 solution is for you to type the delimiter and execute backward-sexp by hand.
 In the local emacs, you should definitely hear the line containing the
 matching opening delimiter (actually emacspeak is more intelligent than to
 just speak the entire line containing the delimiter, but it's hard to
 describe what it does)
 
 > 
 > 
 > 	I also said last week that I'd look at Eterm and discuss
 > suggestions for dealing with application output.Basically, Eterm
 > currently divides applications into two classes based on line or
 > character mode.  For the most part, this is reasonable; I'd like to
 > take a look at a few applications I tend to use  and discuss how eterm
 > deals with their speech, though.
The splitting up of eterm into character and line mode was a decision taken by
the original implementer of eterm, and it's a good one in my opinion too. So
you should give perl bothner the credit for this

 
 > 
 > * Shell, doing things like ls, etc.  I had Eterm in line mode, with
 > emacspeak-eterm-autospeak set to nil (I did set it with C-tC-q).
 > Whenever I type enter, it does speak the shell prompt.  Also, if i
 > type ls and press return, I hear some of the files in my
 > directory--not all of them, but a few.  I suspect there is some case
 > in the advice for eterm-emulate-terminal that should depend on
 > autospeak being non-nil that doesn't.
 Actually, I prefer the way eterm behaves currently with autospeak turned on
 and in line mode.
 What happens is that you hear some of the output; but the prompt flushes the
 speech. If I did not do this, you'd be very unhappy if you ran something that
 produced a ton of output and the dectalk sat around speaking all of it.

 In general, when you want to read the output of your previous command, you
 should use C-c C-r common to both commint shell mode and eterm.
 This will place the point at the top of the batch of process output from your
 previous command; assuming eterm is in line mode, you should be able to arrow
 around and read the output. This gives you more fine grained control than
 hearing the output as it scrolls.
 
 > 
 > * A line mode application with autospeak on: works great for the most
 > part.  It talks, giving all the application output.
 > 
 > * An application like Emacs, running in character mode with autospeak
 > on.  Obviously, this isn't as good as Emacspeak locally, but it works
 > fairly well.  The only thing I notice is that there are some strange
 > situations where Emacspeak will say what it thinks is the next word,
 > even if thats several lines down on the screen.  For example, typing
 > in the scratch buffer of an Emacs, it sometimes says Emacs, reading
 > off the mode line even though I'm near the top of the screen.  I'm
 > strill trying to understand all the interactions in the Eterm code,so
 > I'm not sure what's going on.
I'll try to explain what is happening.
In character mode, the advice basically watches what happens on the screen,
and speaks what happened. This is the only way out, since emacspeak has no
idea what the application at the other end is doing; it also breaks as you
have noticed in the above example. (most screenreaders do too).
What is happening in the specific example you mention is that emacs is
updating the mode-line, and the advice on eterm thinks that is screen activity
and is speaking it to you. Dos screenreaders work around this problem for the
most part by using a timer; they speak things only if the change lasts. Also,
they remember what was on a particular portion of the screen; so if it is just
a screen repaint, they try and not speak it. (they succeed 50% of the time to
80% of the time, depending on the quality of the program)
The above would be hard to do in emacspeak and eterm, and I'm not sure whether
it would be worth the effort.
 
 > 
 > * An application like talk that generates output independent of user
 > input, but that the user still needs to inteeract with.  I'm not sure
 > how this should work; I can see several options.
 Talk is interesting; it's one unix application that I've never enjoyed using
 with my favorite screenreader of old, IBM Screenreader (works like a charm
 with everything else).
 I've got no firm opinions of how talk should behave; basically I get
 irritated seeing characters come on the screen and disappear when the person
 at the other end backspaces to fix a typo.
 
 > 
 > ** The probable easiest option is to turn off autospeak, and just read
 > the other person's comments with review mode commands.  This doesn't
 > work because:
 > 
 > *** Turning off autospeak doesn't prevent Emacspeak from echoing
 > characters as the remote user types them.  I've noticed that it
 > doesn't echo characters I type until the remote side does the actual
 > echo, and think this is a wonderful feature because it protects
 > passwords and lets me know MCI is playing tricks with my network
 > connections Sunday mornings.  However, this feature apparently
 > doesn;doesn't know the difference between what I type and what the
 > other side types.
 Yes, what you say is true. Reason why it does not know the difference between
 what you type and what the other end types is that the output you hear is
 only based on what is echoed to the terminal. This is why your password is
 not being blurted out.
 Incidentally, you should try talk with the windowing support I put into
 emacspeak (will make a release later this evening)
 it might help out some.
 
 > 
 > *** Even worse, whenever a character comes in from the person I'm
 > talking to, my review pointer is moved, and speech is interrupted.
 I implemented the above intentionally; I'll have to think if there is a way
 to do things sensibly to allow what you want. 
 > There should, ideally, be a way for me to readtext without being
 > disturbed by incoming text.  I'm not asking for a "frozen" review mode
 > like some DOS screen readers provide; I don't mind if things get
 > confusing as text gets inserted near the review pointer, but it would
 > be nice if I could avoid having it be warped.  Also, it would be nice
 > if there was a mode where I could exit review mode, type text, and
 > re-enter review mode without having the pointer warp back to the
 > cursor.  (This should not be the default behavior--just an option.)
 Have you thought of using the eterm marker to achieve this functionality? You
 can leave the marker parked at a particular position on the screen, and it
 will not move whatever happens on the screen.
 
 > 
 > 
 > ** Have Emacspeak watch incoming text, speaking it at word breaks or
 > whenever the cursor jumps.  I.E. If I start typing, the cursor jumps
 > to the top, it speaks what's accumulated of the current word.  It
 > looks like this would be fairly difficult to implement in the current
 > code.  DOS screen readers can (several do this OK with talk) work this
 > way because they already have to deal with getting screen updates
 > periodically.  Perhaps, this is the most robust design, and perhaps
 > it's worth implementing in a theoretical since, but Emacspeak works
 > fairly well without knowing about time, and the increased benefit
 > would be fairly small.
 You're right in that what you suggest would be hard to implement. At present,
 I am getting away by just watching what eterm is doing to the screen
 contents; to do what you suggest, I'd have to keep a separate copy of the
 terminal, watch the eterm, update my private copy of the terminal, and do the
 speaking from there. Also, as you point out the incremental benefit to the
 user would be marginal.
 
 > 
 > * Long compiles running on remote systems.  No matter how I deal with
 > these--either in line or character mode, I find it difficult to see
 > how things are going without suspending the compile.  Whenever new
 > text is displayed, speech is interrupted.  This is annoying if you
 > don't want to know how the compile is going, as well.
 I agree this is a problem.
 I've got a suggestion for you. If you want to hack extensively at the remote
 end, and want to use emacspeak, you could do the following:

 Run emacspeak at the remote end.
 Write a tcl dp driver that runs on your local machine and communicates to the
 dectalk. Have the remote emacspeak run a tcl dp driver that sends whatever it
 would send to the dectalk to the tcldp server running on your local machine.

 This way, you would basically get the benefits of a local emacspeak. But of
 course, it requires writing the necessary tcldp magic.
 
  >(I started
 > Kerberos V configuring (about an hour process) with autospeak disabled
 > and left the room.  I came back and about 30 minutes, and my roomate
 > asked what was wrong with my computer; he said it had been mumbling to
 > itself incoherently.  As each test started, the last test line of
 >
 Did you have eterm in line mode?

 Note that eterm behavior in char mode with eterm autospeak is rather weird.
 
 > output was interrupted, producing this effect.)
 > 
 > --Sam
 >
 Hope all of this helps, and watch out for the next release.

 --Raman 
 > 

-- 
Best Regards,
--raman

      Adobe Systems                 Tel: 1 (408) 536 3945   (W14-129)
      Advanced Technology Group     Fax: 1 (408) 537 4042 
      (W14 129) 345 Park Avenue     Email: raman@xxxxxxxxxxx 
      San Jose , CA 95110 -2704     Email:  raman@xxxxxxxxxxx
      http://labrador.corp.adobe.com/~raman/raman.html (Adobe  Internal)
      http://www.cs.cornell.edu/Info/People/raman/raman.html  (Cornell)
-----------------------------------------------------------------------
    Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________