home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / acorn / tech / 76 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  4.2 KB
  1. Path: sparky!uunet!mcsun!uknet!edcastle!jamesh
  2. From: jamesh@castle.ed.ac.uk (James Hammerton)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: How *does* one write a good text editor?
  5. Message-ID: <25258@castle.ed.ac.uk>
  6. Date: 27 Aug 92 15:34:01 GMT
  7. References: <17993@acorn.co.uk>
  8. Organization: Edinburgh University
  9. Lines: 97
  10.  
  11. In article <17993@acorn.co.uk> pcolmer@acorn.co.uk (Philip Colmer) writes:
  12. >If you were writing a text editor which allowed text effects (eg font
  13. >changes, colour changes, etc) to be applied, how would you hold the
  14. >data? My initial thoughts are:
  15. >  
  16. >  * keep the text as one contiguous block of memory
  17.  
  18. Bad idea, you'll end up having to move lots of characters about every
  19. time you insert/delete text. Last year, I had to write a simple text
  20. editor for a computing practical, in which I was introduced to a
  21. simplified version of the standard way of storing text in a text editor.
  22.  
  23. What it involves is this:
  24.  
  25. To keep things simple I'll assume you are storing the text in a fixed
  26. size array. 
  27.  
  28. What you do is you have the text split in two(this is where the cursor
  29. currently is) with one block of text at one end of the array and the
  30. other at the opposite end of the array:
  31.  
  32.         Character to left of cursor    Character to right of cursor
  33.  
  34.             |                    |    
  35.             v                    v
  36. ----------------------------------------------------------------------
  37. |xxxxxxxxxxxxxxxxxxxx                               xxxxxxxxxxxxxxxxx|
  38. ----------------------------------------------------------------------
  39.              ^                    ^        
  40.              |                    |
  41.             Pointer 1               Pointer 2
  42.  
  43. This facilitates efficient insert/deleting of characters and moving
  44. about the text quickly.
  45.  
  46. In order to insert a character you simply place the character into the
  47. array element where Pointer 1 is, and move Pointer 1 on one element.
  48.  
  49. To delete a character, just move  Pointer 1 back an element.
  50.  
  51. To move forward one character, you copy the element at Pointer 2 into
  52. Pointer 1 and move both Pointer 1 and Pointer 2 on one element.
  53.  
  54. To move back one character you would move Pointer 1 back an element,
  55. copy the element at this position to Pointer 2 and move Pointer 2 back
  56. an element.
  57.  
  58. Testing to see if the array is full involves testing whether Pointer 1 &
  59. 2 are adjacent, whilst testing to see if you are at the end of the array
  60. involves testing to see if either pointer 1 is at the first element or
  61. pointer 2 is outside the array bounds.
  62.  
  63. When using this, be sure to figure out what's going on on paper(look for
  64. those boundary conditions!) before you start coding or you'll get some
  65. very strange results(I did!).Also note that you can visualise the two
  66. blocks as being a pair of stacks laid top to top where the operations
  67. involve copying the top element of one stack top the other , or
  68. adding/deleting the top element of one of them. When it comes to
  69. displaying the text, things get tricky and you need to store a cursor
  70. position and have it(and the display) updated accurately. 
  71.  
  72. >  * keep a linked list of effects, specifying the effect to be applied
  73. >    and the start and end character offset for the effect
  74.  
  75. Well I can't help you here as the editor I wrote only involved
  76. searching, inserting, deleting and moving about the text.
  77.  
  78. >  * keep a linked list of line start offsets.
  79. >
  80. See above comment.
  81.  
  82. >The line start offsets are calculated using the font manager to format
  83. >the text into a given width.
  84. >
  85. >When the text is rendered, for a given line, the linked list of
  86. >effects is checked and any that need to be applied are applied to that
  87. >line of text. By keeping the effects in this manner, it makes it
  88. >easier for the code to cope with effects which last more than one
  89. >line.
  90. >
  91. >Does this seem efficient? It certainly seems to work for a fixed block
  92. >of text, but what happens when the user wants to change the text, or
  93. >the effects? Doing the formatting can take some time using my
  94. >approach.
  95. >
  96. >Are there any "standard approaches" for this sort of thing?
  97.  
  98. I have given a simplified version of the 'standard' approach to storing
  99. the text, however I don't know how effects are normally stored(save to
  100. mention that I've seen wordprocessors which use special characters to
  101. mark of where effects are applied).
  102.  
  103. James
  104.  
  105. -- 
  106.   James Hammerton,2nd year Computer Science at University of Edinburgh
  107.   Email: jamesh@uk.ac.ed.castle   Or: jh@uk.ac.ed.dcs                 
  108.