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

From: Tassilo Horn <[email-masked]>
Date: Wed, 14 Oct 2015 21:37:17 +0200

Eli Zaretskii <[email-masked]> writes:

>> > There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it
>> > was supposed to deal only with recording input events for the
>> > purposes of keyboard macros.
>> 
>> I've been running with the latest master with that single commit
>> reverted for the past 10 days and never had this issue again.  So I'm
>> tempted to say that this commit is most probably the culprit.
>
> The only effect of that change is to call record_char on some events
> that might have evaded that before.  record_char does 2 things:
>
>  . it adds the event to recent-keys, a Lisp array
>  . it records the event as part of a keyboard macro, if a macro is
>    being recorded
>
> (There's also the "dribble" part, but I doubt that you are running
> with that enabled.)

No, I don't run that.

> So I wonder how could any of that cause the kind of trouble you
> reported.

Me, too.

> If you undo the revert of that commit, do you start seeing the problem
> again?

I'm back on master now so we'll see.

> If you do, please see which of the "unusual" events, if any, get
> passed to record_char, and whether they are recorded as part of
> recent-keys and keyboard macros

I added some debug code which spits out something like

record_char: 107
  -> NOT storing as part of macro
  -2> set to recent_keys at index 28

where the 107 is the result of formatting the Lisp_Object with "%S", the
second line indicates if store_kbd_macro_char is doing something, and
the -2> line means that the second ASET (recent_keys, ...) invocation in
record_char has been executed.

That's what you had in mind, right?

> (assuming that you are used to define and invoke macros in your
> routine work).

Yes, but not too frequently.  Macros haven't been involved when I had
those issues unless it is possible that some macro recording/replaying
I've done much earlier could have had a side-effect which appears much
later when killing text in a message-mode buffer.

Bye,
Tassilo