home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / gnu / lucid / bug-lucid-emacs / text0195.txt < prev    next >
Encoding:
Text File  |  1993-07-04  |  6.0 KB  |  137 lines
  1. Dave Gillespie wrote:
  2. > 
  3. > Jamie Zawinski writes:
  4. >> What do you think is better about RMS's event and keymap model, beyond
  5. >> the fact that it was there first (i.e., compatibility)?
  6. > 
  7. > One:  Simple keystroke events are represented the same as they were
  8. > before, which goes a long way toward compatibility with Emacs 18.
  9.  
  10. Yes, I realize this; that's why I said "beyond compatibility."  I wanted
  11. to know what you meant besides this.
  12.  
  13. > The mapping between strings and event vectors is much more natural,
  14. > leading GNU Emacs 19 to provide still more compatibility in that area.
  15.  
  16. Keys and buffer-characters are not the same thing.  Strings are made 
  17. of the stuff that buffers are made of.  Keys are not.  Show me how to
  18. represent Control-Shift-A or Control-Backspace in a string.
  19.  
  20. > Two:  The most common events are atomic objects, which means he doesn't
  21. > need to resort to explicit memory management of event objects to keep
  22. > from garbage collecting all day long.
  23.  
  24. You don't need to resort to explicit memory management.  You can drop the
  25. events on the floor and they will be garbage collected like any other lisp
  26. object.  It's simply more efficient to reuse them (this probably only 
  27. matters in one place in all of emacs: the single event that is reused by
  28. the main command loop; and even there it hardly matters at all.)
  29.  
  30. It such a common misconception that you *need* to explicitly manage events
  31. that I'm starting to regret that I made it possible at all...
  32.  
  33. > Three:  Events and keymaps are built from plain Lisp objects, which
  34. > makes them easier to examine during debugging, and easier to construct
  35. > and modify if necessary.
  36.  
  37. And harder to programmatically tell apart from other things ("eventp" is
  38. unpleasantly heuristic.)  But perhaps they should be less opaque; give me
  39. examples where you've wanted this.
  40.  
  41. > Four:  Events are more usage-oriented, less X-oriented.  This will
  42. > probably make for an easier transition to other window systems in
  43. > the future.
  44.  
  45. I very carefully designed the event structures to expose only those 
  46. components that emacs would need when running under *any* window system.
  47. They are not X specific at all; why do you say they are?
  48.  
  49. > The Lucid model acts on the click, whereas RMS's model usually acts on
  50. > the release.
  51.  
  52. Lucid delivers both up and down events, and you can bind commands to either.
  53.  
  54. > This seems to work fine in practice and allows him to generate drag events
  55. > for the user.  (Although he doesn't yet, he could also generate double-click
  56. > events on the second of two consecutive clicks---hint hint, nudge nudge.)
  57.  
  58. Handling of double click and drag events is controverial and varies from
  59. window system to window system.  That's why I didn't build them into the
  60. C substrate, but instead made them be processed up in lisp.  (But this is
  61. a tangential point; if you want to talk more about it, send me mail.)
  62.  
  63. > It also fixes the stupid problem where mouse commands leave a message
  64. > behind only to have it erased when the release-event is processed.
  65.  
  66. Hey, this is just a *bug*, it has nothing to do with the event model per se...
  67.  
  68. > B:  All events have the same representation, which has a certain
  69. > elegance to it.  (This elegance is muffled by the need to keep the
  70. > garbage collector away from event management, though.)
  71.  
  72. See above.
  73.  
  74. > GNU Emacs simply has both.  If there is a character in unread-command-char,
  75. > it stuffs it into the input stream, and if there are events in
  76. > unread-command-events, it stuffs those, too.  There is some order
  77. > of priority, but it doesn't really matter.
  78. > 
  79. > You could still have retained compatibility by using the name
  80. > "unread-command-char" instead of "unread-command-event" for your
  81. > current variable, and allowing it to contain integers as well as
  82. > event objects.
  83.  
  84. The reason I didn't do this is that the canonical use of unread-command-char
  85. is something like this:
  86.  
  87.   (let ((c (read-char)))
  88.     (if (= c 32)
  89.     (progn ... )
  90.       (setq unread-command-char c)))
  91.  
  92. If the user types some key with an unambiguous ASCII equivalent, this works
  93. fine.  But what if the user types Control-Shift-A or Shift-Linefeed, which 
  94. have no ASCII equivalent. Right now, lemacs's read-char signals an error when
  95. C-Sh-A is typed, and returns 10 for Sh-LFD (the same as LFD).  This means that
  96. either this code would fail to work with many otherwise legitimate keystrokes,
  97. or would unread LFD instead of Sh-LFD, which could have a different binding.
  98. Likewise, when this code reads and unreads \010, we lose the distinction
  99. between Control-h and Backspace.
  100.  
  101. Again, maybe you think that compatibility is more important than the feature
  102. that BS and C-h aren't the same thing.  That's a perfectly legitimate opinion.
  103. But I can't think of a way to have both.  
  104.  
  105. Using the FSF19 model, an int would be returned for C-a and an "event" would
  106. be returned for C-Sh-A.  But what about BS/C-h?  Which one returns an event?
  107. Both are equally bad choices.
  108.  
  109. > Maybe RMS' system has evolved since you first saw it.  He represents
  110. > function keys as symbols, and he can also represent a full set of modifier
  111. > bits on printable keys.  In terms of keys themselves, both systems are
  112. > equally expressive as far as I can see.
  113.  
  114. The last time I checked, C-h, C-Shift-H, BS, C-BS, and C-Shift-BS were not 
  115. distinguishable in the FSF version.  Has this changed?
  116.  
  117. > Yes, but there are about a zillion places in Calc where I stuff an
  118. > event that I *know* is a printable character, and I had to change
  119. > every single one of these.
  120.  
  121. I understand that you've had massive compatibility problems.  But in my
  122. defense, I think that Calc is about as atypical an emacs application as you
  123. can find.  Most packages just don't work that way; by far the most common
  124. use of unread-command-char is to unread an arbitrary character read from
  125. the user.
  126.  
  127. > Your model does not detect incompatible code, either, because older
  128. > programs can simply go ahead and store something in "unread-command-char"
  129. > and then silently fail.
  130.  
  131. Yes, this is true.  However, it does issue a compilation warning.  I could
  132. make setq signal an error when storing into unread-command-char, but that
  133. seems pretty perverse...
  134.  
  135.     -- Jamie
  136.  
  137.