home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / gnu / emacs / bug / 1564 < prev    next >
Encoding:
Text File  |  1992-12-13  |  1.6 KB  |  35 lines
  1. Newsgroups: gnu.emacs.bug
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!elf.tn.cornell.edu!eirik
  3. From: eirik@elf.tn.cornell.edu (Eirik Fuller)
  4. Subject: zero repeat count in search-forward
  5. Message-ID: <199212131705.AA11970@DUMPSTER.TC.CORNELL.EDU>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: GNUs Not Usenet
  8. Distribution: gnu
  9. Date: Sun, 13 Dec 1992 07:05:51 GMT
  10. Approved: bug-gnu-emacs@prep.ai.mit.edu
  11. Lines: 22
  12.  
  13. The documentation for search-forward makes no explicit mention of what
  14. happens if the repeat count is zero.  Whether or not the documentation
  15. is changed to mention this case, I think it would be useful to change
  16. the behavior.  The present behavior is mysterious; it seems like an
  17. unforeseen consequence of the way more usual cases are implemented.
  18.  
  19. What seems to be happening is this:  if the cursor is near enough the
  20. beginning of the buffer, it stays put and search-forward returns nil.
  21. Otherwise, it moves backward some distance which seems to have nothing
  22. to do with the contents of the buffer, and search-forward returns t.
  23.  
  24. What I think should happen with a zero repeat count is that
  25. search-forward should leave the cursor where it is and return t,
  26. whether or not the search pattern occurs anywhere in the buffer.  It
  27. seems a conditional early return in search.c:search_command is a
  28. suitable way of doing this.  I don't have diffs for that, but I'm
  29. willing to make some, test them, and send them in if there's any need
  30. for that.
  31.  
  32. This is more than a philosophical question to me; I was forced by this
  33. mysterious behavior to complicate some elisp code I was writing.
  34.  
  35.