home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / editors / 2025 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.editors
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!caen!umeecs!umn.edu!unet.umn.edu!fin
  3. From: fin@unet.umn.edu (Craig A. Finseth)
  4. Subject: Re:  Q: Line # addressing using buffer gap.
  5. Message-ID: <1992Aug18.165508.10181@news2.cis.umn.edu>
  6. Keywords: Finseth, Craft, Of, Text, Editing, buffer, gap
  7. Sender: news@news2.cis.umn.edu (Usenet News Administration)
  8. Nntp-Posting-Host: norge.unet.umn.edu
  9. Organization: University of Minnesota, Networking Services.
  10. References:  <1992Aug18.132755.25619@mks.com>
  11. Date: Tue, 18 Aug 1992 16:55:08 GMT
  12. Lines: 35
  13.  
  14. In article <1992Aug18.132755.25619@mks.com>, ant@mks.com (Anthony Howe) writes:
  15. |> Is there a reasonably fast technique, given a Buffer Gap structure,
  16. |> for finding line number X.  Currently, AE, just performs linear scans
  17. |> for <newline> marks when performing cursor motion, since the
  18. |> assumption is that the majority of movement is localized.
  19.     ...
  20. |> I think I read somewhere about the idea of keeping a table of buffer
  21. |> indexes that correspond to each line.  Then as you insert or delete
  22. |> characters in a given line, all the indexes above line X would need to
  23. |> be updated.  This idea strikes me as being very ugly since the time to
  24. |> update the indexes is dependant on which line you are currently at.
  25. |> If you were at the end of the file, this would be very quick, but if
  26. |> you were at the beginning of the file, this time maybe unacceptable
  27. |> for large files.
  28.  
  29. Most buffer gap systems simply perform linear searches.  Thus, to go
  30. to line X, the editor goes to the start of the buffer and searches
  31. past X-1 newlines.
  32.  
  33. For most files on most systems, this is fast enough.  Hence, no more
  34. hair is required.
  35.  
  36. If you need faster performance, you can keep the list as you
  37. suggested, or you can track the current line number, updating it as
  38. you move past newlines.  Marks can also record the line number (you
  39. would have to update or invalidate the line number part of marks after
  40. the point when changes were made).
  41.  
  42. But all of this is hairy, and I would first find out if
  43. simple-and-straightforward is fast enough.
  44.  
  45. What to do if it isn't fast enough will vary depending upon the
  46. characteristics of your system and the user's needs and expectations.
  47.  
  48. Craig
  49.