home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / gnu / lucid / bug-lucid-emacs / text0193.txt < prev    next >
Encoding:
Text File  |  1993-07-04  |  1.8 KB  |  39 lines
  1. Dave Gillespie wrote:
  2. > 
  3. > Lucid threw out RMS's event and keymap model, for example.  Maybe Lucid's
  4. > approach was better (not entirely clear; each system has plusses and
  5. > minusses).
  6.  
  7. What do you think is better about RMS's event and keymap model, beyond
  8. the fact that it was there first (i.e., compatibility)?
  9.  
  10. > One little thing I noticed recently is that the unread-command-char
  11. > variable is still supported, *as well as* an alternative that holds
  12. > events instead of chars.  Lucid simply deleted the old variable,
  13. > and it was a giant pain for me to fix all the references to it in
  14. > Calc.  I sure wish Lucid had put compatibility at a higher priority.
  15.  
  16. The new event model in Lucid Emacs is a portability problem, to be sure.
  17. I did what I could to remain compatible with the old model (keeping
  18. last-command-char as the ASCII equivalent of last-command-event, for
  19. example.)  But I could not think of a way to keep unread-command-char 
  20. and still *make progress*.
  21.  
  22. My goal was to make emacs a better editor than it was before.  Perhaps you
  23. don't think that removing the restriction to the ASCII character set was
  24. worth the pain; I think it was.
  25.  
  26. If you don't like the design decisions I made, please suggest better
  27. ones.  Converting to ASCII and back loses information.  If a package were
  28. to read and unread a character as ASCII, it could easily cause the wrong
  29. command to be executed.  I could put this hack in, and it would mostly
  30. work most of the time, but it's the wrong thing.  There are arguments in
  31. favor of improving software by adding kludge on top of kludge instead of
  32. stepping back and reevaluating the original decisions.  I chose not to
  33. take that approach.  Maybe you disagree.  But I gave you an editor more
  34. than a year ago that I think was a vast improvement over what I started
  35. with.
  36.  
  37.     -- Jamie
  38.  
  39.