Re: comint-insert-input

[Stefan Monnier]

>     I think the best way to fix this, is to change the behavior of "e" so
>     that it doesn't complain when it's bound to a non-mouse event.

> That would be straining the definition of "e", since it is supposed to
> find the first event with parameters.  We could fudge that, but it
> doesn't seem clean.  Also, we would have to check the other uses of
> "e" to see if they would get bad results.

If there is no "first event with parameter", (interactive "e") signals
(error "comint-insert-input must be bound to an event with parameters").

So what I suggest to do is to remove this error and to instead (when there
is no event with parameters) pass the first event (or the last, it
really doesn't matter much when neither has parameters) instead of
signalling an error.  See patch below.

This should have no impact on the other uses of "e" since it only has impact
on bindings which are currently never used (since they currently don't
work).

The only impact would be that with my suggestion, binding a command that
uses "e" to a key whose events don't have parameters would now not fail
as cleanly as they currently do.  Instead, depending on the code, they will
either work fine, or signal another error like (wrong-type-argument listp
65) because the code tried to take the `car' of the event, or even
potentially something more "byzantine" where it doesn't do what it's
supposed to.

> It would probably be better to put this function back the way it was
> and add a comment saying why it does not use e.

That's a more local change, indeed.  The reason I suggested the further
reaching change, is because I've already had several times to replace "e"
with (list last-input-event) in order to allow a command to be bound both to
mouse events and to regular key events.

Another suggestion (for post-21.4) is to make sure that a (interactive
"foo") spec can easily (and mechanically, by an elisp function) be turned
into a 100% equivalent (interactive (list bar)) spec.  Currently in the case
of "e", the closest I could find was last-input-event, but it is not
strictly equivalent.


        Stefan


--- callint.c   21 nov 2004 19:50:51 -0500      1.137
+++ callint.c   25 jan 2005 07:59:29 -0500      
@@ -96,6 +96,7 @@
 e -- Parametrized event (i.e., one that's a list) that invoked this command.
      If used more than once, the Nth `e' returns the Nth parameterized event.
      This skips events that are integers or symbols.
+     If there are no parameterized events, use non-parameterized events.
 f -- Existing file name.
 F -- Possibly nonexistent file name.
 i -- Ignored, i.e. always nil.  Does not do I/O.
@@ -415,6 +415,9 @@
   for (next_event = 0; next_event < key_count; next_event++)
     if (EVENT_HAS_PARAMETERS (XVECTOR (keys)->contents[next_event]))
       break;
+  /* If there is no event with parameter, just use regular events.  */
+  if (next_event >= key_count)
+    next_event = 0;
 
   /* Handle special starting chars `*' and `@'.  Also `-'.  */
   /* Note that `+' is reserved for user extensions.  */
@@ -677,14 +678,15 @@
 
        case 'e':               /* The invoking event.  */
          if (next_event >= key_count)
-           error ("%s must be bound to an event with parameters",
+           error ("No more events for %s",
                   (SYMBOLP (function)
                    ? (char *) SDATA (SYMBOL_NAME (function))
                    : "command"));
          args[i] = XVECTOR (keys)->contents[next_event++];
          varies[i] = -1;
 
-         /* Find the next parameterized event.  */
+         /* Find the next parameterized event, if applicable.  */
+         if (EVENT_HAS_PARAMETERS (args[i]))
          while (next_event < key_count
                 && ! (EVENT_HAS_PARAMETERS
                       (XVECTOR (keys)->contents[next_event])))