Your DECtalk Express has old firmware. Use the Emacspeak
command `C-e d V' to find out your version. You should be running a
version no older than 4.2bw from March 1995. If you have an earlier
version, you can find an updated version at
http://www.ultranet.com/~rongemma/tips_upd.htm, a WWW
site maintained by Ron Jemma of the Dectalk Group at DEC.
Alternatively, you can send email to Anne Nelson at
DECnelson@dectlk.enet.dec.com. The most recent version at this
writing is 4.3 release AA X01 May 20 1996.
On occasion when reading the DECtalk will produce high pitch tones that last for several words or more, if this happens in a buffer it will often repeat within the same buffer.
The problem is due to remaining bugs in the Dectalk firmware. When emacspeak produces tones, especially when split caps is on, the dtk sometime goes into squealing mode.
If you notice this happening in particular text documents, just turn off split caps mode locally with `C-e d s'.
What is the significance of the message "No library autorevert in search path" which is spoken (or at least queued for speech) when emacspeak 7.0 starts?
It's completely insignificant. autorevert is a new minor mode provided by emacs 20 and emacspeak looks for it and if found speech-enables it.
What is the best way to change Emacspeak defaults for things such as speech rate, default punctuation mode, etc.?
Just put the needed changes in your .emacs file. ".emacs" is a file in your home directory that is loaded by emacs when it starts (shortly after reading emacspeak). It is the place to do personal modifications.
Here is an example which resets the speech rate and redefines a function (courtesy of Greg Priest-Dorman priestdo@cs.vassar.edu):
;;
(dtk-set-rate 380 1)
;;
(defun emacspeak-speak-time ()
"Speak the time. "
(interactive)
(dtk-speak (format-time-string "%A %B %e, %I %M %p"
(current-time) )))
;;
An error message was displayed on the screen, but not reported by Emacspeak
In general, if emacs hits an error and you don't get to hear the message because it went by too quickly, here is what you should do:
1) Switch to the *Messages* buffer and see if you see the message there. 99% of the time it will be there.
2) If some portion of emacs or an emacs application throws an error without leaving an appropriate message in the *Messages* buffer, then turn on emacs' debugging facility by `M-x set-variable ret' `debug-on-error ret' `t ret' this sets debugon-on-error to true now repeat what caused the error you will be placed in a backtrace buffer.
Warning: do not read the entire contents of the backtrace
buffer at one shot with emacspeak. Go line by line.
(courtesy of T. V. Raman raman@Adobe.COM)
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.
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.
(courtesy of T. V. Raman raman@Adobe.COM)
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.
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.