bug#35238: 27.0.50; Clarify eventp behaviour with booleans

[Basil L. Contovounesios]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> As mentioned in a past commit[1], nil is not an event.
>> Since the car of a mouse click event is considered its type,
>> shouldn't (nil) also be rejected as an event?
>
> Not sure it's worth the trouble (there are already lots of other objects
> that aren't events but for which eventp returns non-nil).

Sure, but the following would at least make eventp treat nil
consistently:

diff --git a/lisp/subr.el b/lisp/subr.el
index bdf98979c4..407bd6379d 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -1227,12 +1227,13 @@ listify-key-sequence
                          c)))
            key)))
 
-(defun eventp (obj)
-  "True if the argument is an event object."
-  (when obj
-    (or (integerp obj)
-        (and (symbolp obj) obj (not (keywordp obj)))
-        (and (consp obj) (symbolp (car obj))))))
+(defun eventp (object)
+  "Return non-nil if OBJECT is an input event or event object."
+  (or (integerp object)
+      (and (symbolp (if (consp object)
+                        (setq object (car object))
+                      object))
+           (not (keywordp object)))))
 
 (defun event-modifiers (event)
   "Return a list of symbols representing the modifier keys in event EVENT.

>> Should t be counted as an event?
>>
>>   (eventp t)    ; => t
>>   (eventp '(t)) ; => t
>
> Not sure if we ever generate such an event, but what would be the
> benefit of rejecting it?

I don't know, it could even be detrimental; I was just curious.

Thanks,

-- 
Basil