home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / alt / lucidem / bug / 420 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.5 KB  |  51 lines
  1. x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Tue, 5 Jan 1993 15:59:05 EST
  2. Date: Tue, 5 Jan 1993 12:55:13 PST
  3. Message-ID: <9301052055.AA18807@thalidomide.lucid>
  4. X-Windows: A terminal disease.
  5. From: jwz@lucid.com (Jamie Zawinski)
  6. Sender: jwz%thalidomide@lucid.com
  7. Subject: Re: Shouldn't the audio part be moved out of lemacs?
  8. References: <9301051623.AA17021@geant.cenatls.cena.dgac.fr>
  9.     <Pine.3.05.9301051114.B17104-b100000@trillian>
  10. Newsgroups: alt.lucid-emacs.bug
  11. Path: sparky!uunet!wendy-fate.uu.net!bug-lucid-emacs
  12. Lines: 37
  13.  
  14. The reason I built the audio code into emacs instead of just forking whatever
  15. "play" program the system provides is that playing sounds is different from
  16. something like ispell in that emacs plays sounds as part of its error-handling
  17. routines.  because of the time-criticalness of this, I don't want emacs to
  18. have to access the file system to play a sound.  Execing "play" would mean at
  19. least two accesses: getting the play executable (actually this would probably
  20. be dozens, since it would have to search the path) and then reading the sound
  21. file.  Getting NFS lossage just because you typed ^G would be very bad news.
  22.  
  23. > One solution would be to use a interface similar to "ispell". Last night I
  24. > hacked up a simple program "eplay" which waits for the name of a sound
  25. > file, opens the audio port, plays it, closes the audio port and loops back
  26. > to the beginning. 
  27.  
  28. This sort of thing would be ok, if you could hand it sound data instead of
  29. just a filename, but the system doesn't provide such a program: you'd have to
  30. write the audio-handling code yourself, which is the hard part.  So why not
  31. just link it in to emacs directly and avoid the overhead of having to fork a
  32. process?
  33.  
  34. > The elisp interface should fit on a single page. (It is a bit messy as it
  35. > seems that the (only?) C-primitive ring_bell[_hook] is called within a few
  36. > built-in defuns: play-sound-file play-sound ding)
  37.  
  38. But since it's called indirectly from cmd_error, there are interrupt issues
  39. involved: it would be hard to make running arbitrary lisp code from the error
  40. handler work.  You'd have to run that code with interrupts off, and would
  41. probably have GC protection problems as well.
  42.  
  43. > Furthermore, lemacs will (hopefully soon) become a full X-client which
  44. > requires the sound to "travel" as well. 
  45.  
  46. I don't know quite what you mean by "full X client," but I think lemacs is
  47. one...  As you know, X has nothing to say about sound.  (I guess you could
  48. say it keeps quiet on the issue...)
  49.  
  50.     -- Jamie
  51.