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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Uh, well, does "by hand" mean reimplement make_lispy_event?  I've tried
cheating and calling that on a copy of the actual input_event.  At least
that compiles, emacs starts, and after some time my th-event-buffer will
have the number 7 at index 0, and eventually it'll segfault.

But I'm probably barking up the wrong tree anyway.
kbd_buffer_store_event doesn't seem to be called very frequently;
certainly not for every event.

--8<---------------cut here---------------start------------->8---
modified   src/keyboard.c
@@ -3412,6 +3412,15 @@ kbd_buffer_nr_stored (void)
 void
 kbd_buffer_store_event (register struct input_event *event)
 {
+  printf ("kbd_buffer_store_event: %d\n", event);
+  struct input_event event_copy = *event;
+  printf ("    copy:               %d\n", &event_copy);
+  Faset (Vth_event_buffer, Vth_event_buffer_idx, make_lispy_event 
(&event_copy));
+  if (Vth_event_buffer_idx == make_number (99))
+    Vth_event_buffer_idx = make_number (0);
+  else
+    Vth_event_buffer_idx = call2 (Qplus, Vth_event_buffer_idx, make_number 
(1));
+
   kbd_buffer_store_event_hold (event, 0);
 }
 
@@ -11131,6 +11140,14 @@ syms_of_keyboard (void)
   defsubr (&Sposn_at_point);
   defsubr (&Sposn_at_x_y);
 
+  DEFVAR_LISP ("th-input-event-buffer", Vth_event_buffer,
+              doc: /* The last 100 events.  */);
+  Vth_event_buffer = Fmake_vector(make_number (100), Qnil);
+
+  DEFVAR_LISP ("th-input-event-buffer-idx", Vth_event_buffer_idx,
+              doc: /* Current index in th-event-buffer.  */);
+  Vth_event_buffer_idx = make_number (0);
+
   DEFVAR_LISP ("last-command-event", last_command_event,
                     doc: /* Last input event that was part of a command.  */);
 
--8<---------------cut here---------------end--------------->8---


>> 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.

Yeah, that commit seems to be unrelated anyway.

> > But looking at the changes of this commit, I think the functions it
> > touched are not used when editing in a message-mode buffer.
> 
> There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it was
> supposed to deal only with recording input events for the purposes of
> keyboard macros.

Ok, I'm running with that being reverted now.

Bye,
Tassilo