home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / gnu / lucid / bug-lucid-emacs / text0201.txt < prev    next >
Encoding:
Text File  |  1993-07-04  |  1.3 KB  |  34 lines
  1. Richard Mlynarik writes:
  2. > It is one thing to argue that such perversions might make sense for
  3. > some reason of compatibility, but quite another to claim that
  4. > representing hash-tables and keymaps and events and so forth in terms
  5. > of conses and vectors and symbols is in any way a feature.
  6.  
  7. GNU Emacs doesn't have hash-tables of any sort, as far as I can tell.
  8. If it did you're right that they would work better as primitive Lisp
  9. objects.  It remains to be seen whether GNU Emacs 19 will suffer from
  10. using alists instead of hash tables to store function key and mouse
  11. maps.  If the maps get big enough, it will.
  12.  
  13. The GNU keymaps are admittedly pretty baroque.
  14.  
  15. > (Why aren't windows and processes and window configurations represented in
  16. > such a way in FSFmacs anyway?)
  17.  
  18. Windows and processes probably contain data that is more conveniently
  19. dealt with on strictly a C level.  There might also be funny business
  20. in there with the garbage collector; there certainly is with buffers
  21. and markers.
  22.  
  23. I've often wondered why window configurations are opaque.  It has
  24. occasionally been frustrating that they were.
  25.  
  26. > By the way, FSFmacs doesn't allow "(fillarray (make-keymap))" any
  27. > more.  This "incompatibly broke" a bunch of code I wrote.
  28.  
  29. Very true.  I see why they had to do it, but it's still a shame that
  30. keymaps couldn't be 100% backward compatible.
  31.  
  32.                                 -- Dave
  33.  
  34.