home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / pop / 219 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  1.6 KB
  1. Path: sparky!uunet!noc.near.net!nic.umass.edu!dime!roo.cs.umass.edu!pop
  2. From: pop@cs.umass.edu ( Robin Popplestone )
  3. Newsgroups: comp.lang.pop
  4. Subject: Folding in VED
  5. Message-ID: <59104@dime.cs.umass.edu>
  6. Date: 25 Jan 93 18:43:14 GMT
  7. Sender: news@dime.cs.umass.edu
  8. Organization: University of Massachusetts, Amherst
  9. Lines: 23
  10. Originator: pop@roo.cs.umass.edu
  11.  
  12.  
  13. > Before this glorious future arrives, there is one feature I would love
  14. > to have incorporated into VED as soon as possible -- and that's
  15. > folding.  I'm always frustrated that when I'm writing a large program
  16. > I can't collapse a bunch of related functions togther into a single
  17. > line.  I thinking that text "folding" (as in the original OCCAM editor)
  18. > could well add something special to VED.
  19.  
  20. It is always a mistake to pronounce something "hard". But it seems to
  21. me that there is a real problem here, namely the mapping between screen
  22. space and buffer-space. In VED (unlike EMACS) a buffer is conceptually
  23. 2-dimensional (EMACS has a 1-dimensional model of a buffer as a string,
  24. which is no doubt optimised behind-the-scenes). Thus the mapping from
  25. buffer space to screen space in VED is a linear transform (if you play the
  26. old projective-geometry hack of homogeneous coordinates). This is deeply
  27. built into VED. Folding would of course change the mapping.
  28.  
  29. Similar probems arise with a system like Pantechnicon. Here, each logical
  30. sub-unit has an associated size, and the mapping from buffer-space to
  31. screen-space requires a recursive descent through the hierarchy (do-able in
  32. log time if there is a bound on the tree-branching-ration).
  33.  
  34. Robin
  35.