home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / lucidem / help / 822 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.7 KB  |  60 lines
  1. x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 24 Dec 1992 22:46:22 EST
  2. Date: Thu, 24 Dec 1992 19:47:25 PST
  3. Message-ID: <9212250347.AA24601@thalidomide.lucid>
  4. X-Windows: The Cutting Edge of Obsolescence.
  5. From: jwz@lucid.com (Jamie Zawinski)
  6. Sender: jwz%thalidomide@lucid.com
  7. Subject: Re: Idea: graphical extents
  8. References: <9212250147.AA15972@thymus.synaptics>
  9. Newsgroups: alt.lucid-emacs.help
  10. Path: sparky!uunet!wendy-fate.uu.net!help-lucid-emacs
  11. Lines: 47
  12.  
  13. In message <9212250147.AA15972@thymus.synaptics> Dave Gillespie wrote:
  14. >
  15. > So all the regular optimizations still apply, e.g., if both markers of an
  16. > extent are off the beginning or end of the screen, the display routines can
  17. > ignore the extent.
  18.  
  19. Well, one could do that, but that's not what happens now when the endpoints of
  20. an extent are off the screen.  Redisplay partitions the displayed portion of
  21. the buffer into nonoverlapping "extent fragments", and then displays those.
  22. It doesn't matter where the "real" endpoints are.
  23.  
  24. > Rectangle extents would allow a more appropriate kind of highlighting for
  25. > rectangle operations.  I posted a suggestion along those lines a while ago
  26. > here, but I was envisioning some way of faking it up with a group of regular
  27. > extents.  Imagine how easy it would be with a single rectangle extent
  28. > instead!
  29.  
  30. Imagine how much easier it would be to fake it up with regular extents than to
  31. implement rectangle extents! :-)
  32.  
  33. > As soon as you have filled objects you run into the issue of drawing order,
  34. > though, which the current extent data structure probably isn't well-suited
  35. > to handle.
  36.  
  37. (Actually it is.)
  38.  
  39. > Suppose you wanted to display a change bar to the right of a set of lines in
  40. > a buffer.
  41.  
  42. We're going to have a column down the left side of the screen that glyphs will
  43. be displayed in (for example, the breakpoint and PC-indicator icons
  44. corresponding to a line.)  Extents will have attributes which are the glyphs
  45. to display, and whether those glyphs should go in the "info column" instead of
  46. inline with the text.  (This was actually mostly working at one time, but then
  47. we had to cut our losses w.r.t. redisplay.)  "Display as a change bar" will
  48. probably be another option (we may want Energize to use that to mark those
  49. functions which will be recompiled at the next build, instead of a changed
  50. background color as we do now.)
  51.  
  52. > Anyway, I may someday have time to work on this myself, but I wouldn't be
  53. > surprised if Jamie or another person who already knows the lemacs internals
  54. > could do it in an afternoon.  Hint, hint.  :-)
  55.  
  56. Ha!  I can almost guarentee that you'll have to rewrite half of redisplay to
  57. make this work.  (This is axiomatic for most interesting emacs tasks...)
  58.  
  59.     -- Jamie
  60.