home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / gnu / emacs / help / 3530 < prev    next >
Encoding:
Text File  |  1992-07-28  |  1.4 KB  |  31 lines
  1. Newsgroups: gnu.emacs.help
  2. Path: sparky!uunet!cis.ohio-state.edu!gnu.ai.mit.edu!rms
  3. From: rms@gnu.ai.mit.edu (Richard Stallman)
  4. Subject: Emacs Lisp: interactive calling of C subroutines
  5. Message-ID: <9207282039.AA19376@mole.gnu.ai.mit.edu>
  6. Sender: daemon@cis.ohio-state.edu
  7. Organization: Gatewayed from the GNU Project mailing list help-gnu-emacs@prep.ai.mit.edu
  8. References: <ACEVEDO.92Jul28095546@hippocrene.mit.edu>
  9. Date: Tue, 28 Jul 1992 12:39:15 GMT
  10. Lines: 19
  11.  
  12. There are quite a few built-in functions that get special magic
  13. treatment in Emacs.  You have found some of them.
  14.  
  15. In general, redefining a standard Emacs function (whether written in C
  16. or Lisp) is a bad idea, even if you don't encounter a problem such as
  17. this one.  Lately I've noticed that a number of Emacs Lisp packages do
  18. redefine standard functions, so I suspect that people are getting the
  19. idea that this is reasonable practice.  Actually, it is asking for
  20. trouble, because it is unmodular.  Unless the purpose of your package
  21. is to make a particular standard Emacs function behave differently,
  22. you shouldn't mess with it.
  23.  
  24. If you maintain, or are writing, a Lisp package that redefines
  25. standard Emacs functions, please look for a way to change it to stop
  26. doing so.
  27.  
  28. Once in a while, there is no other way to get a job done; but in those
  29. cases, it might be better to add a new hook to Emacs to provide an
  30. alternative.
  31.