home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / gnu / emacs / help / 3995 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.5 KB  |  62 lines
  1. Newsgroups: gnu.emacs.help
  2. Path: sparky!uunet!cis.ohio-state.edu!cs.uiuc.edu!liberte
  3. From: liberte@cs.uiuc.edu
  4. Subject: Emacs bugs
  5. Message-ID: <9209040329.AA22629@cookie-crisp>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: Gatewayed from the GNU Project mailing list help-gnu-emacs@prep.ai.mit.edu
  8. Date: Thu, 3 Sep 1992 09:48:51 GMT
  9. Lines: 51
  10.  
  11.     From: rms@gnu.ai.mit.edu (Richard Stallman)
  12.  
  13.     Have you sent a bug report with a detailed recipe for reproducing the
  14.     problem?  If not, please do--so we can get it *fixed*.
  15.  
  16.     Users often treat bugs as immutable facts of nature; they talk about
  17.     what bugs exist as if they just had to learn to live with them or
  18.     avoid them.
  19.  
  20. There are several reasons that bugs don't get reported.  I suggest some
  21. remedies.
  22.  
  23. 1. It may difficult to tell whether something is a bug or some
  24. kind of weird feature.  But if emacs crashes or hangs, this is clearly
  25. a bug.  Weird features can be considered bugs if there is no good
  26. reason for them, but that is often difficult to tell without experience.
  27. If the printed documentation differs from the on-line
  28. documentation, or from Emacs' behavior, there is a bug in one of them.
  29.  
  30. 2. It may be a bug in some non-standard package or modification of Emacs.  
  31. Non-standard modifications of Emacs should be clearly indicated to users.
  32. Go to the author of the modifications first if they are at all suspect.
  33. Non-standard packages should be used with some caution, particularly those
  34. that modify standard behavior.  Package writers should avoid such
  35. modifications and generally warn users of potential problems or
  36. known bugs.
  37.  
  38. 3. It may be difficult to identify or reproduce a bug.  Experience helps
  39. alot here.  Emacs provides some utilities that help, but there is room for
  40. more.  
  41.  
  42. 4. It takes time and effort to put together a bug report, even
  43. after identifying the bug.  If the reason for the bug is not clear,
  44. part of the problem is identifying enough of the environment so others
  45. can reproduce the problem.  Utilities can help here.
  46.  
  47. 5. It may have already been reported, so why should I bother? 
  48. A known bug list would help.  With each distribution, include the
  49. list in the etc directory with a reference to the ftpable file for
  50. the current list.
  51.  
  52. Emacs maintainers shouldn't object too strongly to getting vague
  53. rumors of bugs.  That may be the most that some users can offer
  54. for various reasons.  Discouraging vague reports is just discouraging.
  55. Instead, encourage users by making it easier.
  56.  
  57. Dan LaLiberte
  58. liberte@cs.uiuc.edu
  59. (Join the League for Programming Freedom: league@prep.ai.mit.edu)
  60.  
  61.  
  62.