GNU bug report logs - #21313
25.0.50; Strange errors from dbus-handle-event

Previous Next

Full log

View this message in rfc822 format

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 21313 <at> debbugs.gnu.org
Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Wed, 14 Oct 2015 21:37:17 +0200

Eli Zaretskii <eliz <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.