Re: Emacspeak problems with emacs20

["T. V. Raman" <raman@xxxxxxxxxxx>]

Bryan Smart writes:
 > Hello.
 > 
 > I'd say that the terminal emulator functionality is the most problematic
 > portion of Emacspeak.
It's not an emacspeak problem-- it's a terminal problem.
Getting a terminal emulator working correctly inside emacs
 > is not a joke--
and eterm is an excellent piece of work, but 
depending on how some old app behaves you will (or should
 > always expect to)
see some weirdness.

After all, remember all of these UNIX terminal apps work
from all kinds of terminals ranging from vt52's to new devices.
  
>I have several problems myself, including...
 > 
 > *  When starting a term buffer, no output is spoken in line mode by
 > Emacspeak until the cursor has made it about half way
 > down the screen
I've not seen this-- and I am running emacs 20.

when you start term it is in character mode.
when you switch to line mode make sure the cursor is at the
end of the buffer--
otherwise what you send will never go to the shell.

Also,  in general use M-x shell 
(comint-mode) for running things you would run in line mode
in eterm--
it's been around longer and far more robust. M-x term
specializes in its character-mode
of terminal emulation and may not always take care of
everything in line mode.
 > (usually by repeated tapping of the return key).
 > 
 > *  Sometimes, after long sessions with a term buffer, I will experience
 > similar problems as do you with spech in the term becoming very flaky.
 > Output may or may not be spoken (I have not determined the pattern).
 > 
if the term becomes flaky, enter character mode and issue a
reset.
the above is usually a result of running some curses based
app that leaves the terminal in a screwy state.
 > Additionally, I'd like to report this strange behavior with Emacspeak.
 > This is not "rain on Raman" day, but just thought I would provide this info
 > so you guys could have a look
 > 
 > *  Sometimes the Emacspeak read by character mode will
 > become...well...flaky.  That is such an undescriptive word, but I'm unable
 > to sum it up in a word.  Strange things will start to happen, such as
 > instead of speaking a letter, the DecTalk will say "space" followed by the
 > letter.  A reset will correct this problem.
As I said above that is a symptom of something leaving the
  terminal in a weird state.
Many curses based apps follow slightly different conventions
  on where they leave the cursor while you edit--
60-70% of them leave the cursor just after the character you
  typed with a null character after point --others leave a
  space character there which is what you hear.

Experiment between setting TERM to vt100 and eterm.
Depending on whether the app was linked against curses or
ncurses (former uses TERMCAP and latter uses TERMINFO)
you will get different results.
 > 
 > *  Also, it seems as if the read by character mode uses a higher speech
 > rate than the regular reading speed of the DecTalk.  I
 > can understand the
This has always been the case.
See the online documentation --dtk-set-character-scale sets
  a scaling factor by which speech rate is scaled.
 > DecTalk at high speeds, but am unable to use a greater speed than 450,
 > because characters are uninteligable at higher speeds.
 > 
 > Thanks
 > Bryan
 > 
 > --
 > Bryan R. Smart
 > E-Mail: bsmart@xxxxxxxxxxx

-- 
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/        (Adobe Intranet)
      http://cs.cornell.edu/home/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.
____________________________________________________________