bug#21313: 25.0.50; Strange errors from dbus-handle-event

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de,  rpluim@gmail.com,  21313@debbugs.gnu.org
> Date: Sat, 03 Oct 2015 10:10:58 +0200
> 
> In toplevel form:
> notifications.el:37:1:Error: Wrong type argument: number-or-marker-p, 
> [(dbus-event :system 2 2 "org.freedesktop.DBus" nil nil nil 
> dbus-call-method-handler) nil nil nil nil nil nil nil nil nil nil nil nil nil 
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
> nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
> nil nil nil nil nil nil nil nil nil nil]
> Makefile:269: recipe for target 'notifications.elc' failed
> make[2]: *** [notifications.elc] Error 1

You need to run this under GDB to see what's going on.

> I guess that naive approach won't work because make_lispy_event is not
> free of side-effects.  It actually modifies the event so calling it
> twice per event has negative consequences.

Indeed, you probably should construct the Lisp object from the event
by hand.  Especially since we suspect some events might be invalid.

> Well, I now try following Michaels suggesting of reverting this one
> commit about `unread-command-events'.

That's okay, but only as a means of switching your attention to the
alternative source of those bogus events (like unread-command-events).
The commit mentioned by Michael is not going to go away, as it fixes a
bad problem.  However, it might need some adjustments to prevent
adverse side effects, if indeed reverting it will solve these
problems.