Skip to Content.
Sympa Menu

emacspeak - [Emacspeak] Some auditory icon related bugs/issues

Subject: Emacspeak discussion list

List archive

[Emacspeak] Some auditory icon related bugs/issues

Chronological Thread 
  • From: Tim Cross <theophilusx AT>
  • To: emacspeak AT
  • Subject: [Emacspeak] Some auditory icon related bugs/issues
  • Date: Tue, 23 Apr 2024 15:20:29 +1000

Hi Raman,

I've run into a couple of issues relating to auditory icons. One is a
bug, the other is not really a bug, but an issue none the less.


I discovered this one when I switched from pactl to SoX for playing the
icons. I was getting an error (wrong-tyupe-argument stringp nil) from
the code which creates the play process. This was for when Emacspeak
tried to play the emacspeak icon (emacspeak.ogg). I found two issues

First, emacspeak-preamble.el assumes that emacspeak.ogg is in the root
of the sounds directory, but it is actaully in the prompts
sub-directory. I've attached a diff fixing this.

Second. As emacspeak.ogg is not in a 'theme' directory, it does not seem
to get loaded into the emacspeak-sounds-cache hash table. As a
consequence, when emacsspeak() tries to play the emacspeak icon using
emacspeak-play-icon it fails as emacspeak-sounds-resource will return
nil. I think it could be a good idea to add a nil check to
emacspeak-sounds-resource and have it return a default icon file path as
any nil value returned now will result in emacspeak-play-icon failing
and I've found such failure can cause lots of usability issues (see


The other issue I encountered is with the custom setting for
emacspeak-play-program. It assumes SoX play is in /usr/local/bin and
will set that as the path if you select SoX. However, on my Fedora
system, as SoX is an available standard package, the sox play probram is
in /usr/bin. Setting it to a non-existent file causes
emacspeak-play-icon to fail, whihc in turn causes other issues. For
example, when I tried to save my custom change, Emacs became
unresponsive and just kept rpeeating "Returning to top level". I could
not get a backtrace, but did get an error message in the *Messages*
buffer stating that emacspeak-minibuffer-exit-hook was failing.

Turns out emacspeak-minibuffrer-exit-hook was failing because it could
not play the 'close-object' icon and this caused a cascade of errors
that are difficult to track down because once emacspeak-play-icon starts
to fail, it impacts many other commands.

Not sure how you would like to fix this. I feel part of the problem is
that 'play' as an executable name is too generic to reliably auto-detect
(and do something similar to what is done with pactl). However, I did
notice that on Fedora at least, play is actually a sym link from the
'sox' binary.

Perhaps it would be better to update the custom definition for
emacspeak-play-program to either look for the sox binary and set that as
the path or simplify things and just allow the user to enter a path

diff --git a/lisp/emacspeak-preamble.el b/lisp/emacspeak-preamble.el
index 3ecdb9bff..b1648e7a4 100644
--- a/lisp/emacspeak-preamble.el
+++ b/lisp/emacspeak-preamble.el
@@ -92,7 +92,7 @@

 (defconst emacspeak-icon
-  (expand-file-name "emacspeak.ogg" emacspeak-sounds-dir)
+  (expand-file-name "prompts/emacspeak.ogg" emacspeak-sounds-dir)
   "Emacspeak startup icon.")

 ;; local media dir

Archive powered by MHonArc 2.6.19+.

Top of Page