Severe lossage from unread-command-events

Severe lossage from unread-command-events

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]


Hi,

run the included test file using

emacs -Q -l timer-test.el

and then open the generated dribble file /tmp/mydrib.  On my computer,
it looks something like

0000000000000000001111111111111111111222222222222222222223333333333333333444444444444444444555555555555555556666666666666666667777777777777777778888888888888888899999999999999999

which means that of 4000 events having an effect in the scratch buffer,
about 5% (a non-deterministic amount) are actually recorded in the
dribble file.  In particular, it looks like only the first of several
events placed into unread-command-events at one point of time will ever
see the dribble file.  While I am only moderately interested in actually
generating a useful dribble file, the same holds for macro recording.
And I have an actual application which is severely impacted here.

Note that _all_ of the events (usually) are actually processed as input
in the *scratch* buffer.  It is only the recording of them which falls
really, really flat on its face.


[-- Attachment #2: timer-test.el --]
[-- Type: application/emacs-lisp, Size: 463 bytes --]

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]



-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 05 Aug 2015 17:46:50 +0200
> 
> run the included test file using
> 
> emacs -Q -l timer-test.el
> 
> and then open the generated dribble file /tmp/mydrib.  On my computer,
> it looks something like
> 
> 0000000000000000001111111111111111111222222222222222222223333333333333333444444444444444444555555555555555556666666666666666667777777777777777778888888888888888899999999999999999
> 
> which means that of 4000 events having an effect in the scratch buffer,
> about 5% (a non-deterministic amount) are actually recorded in the
> dribble file.  In particular, it looks like only the first of several
> events placed into unread-command-events at one point of time will ever
> see the dribble file.  While I am only moderately interested in actually
> generating a useful dribble file, the same holds for macro recording.
> And I have an actual application which is severely impacted here.
> 
> Note that _all_ of the events (usually) are actually processed as input
> in the *scratch* buffer.  It is only the recording of them which falls
> really, really flat on its face.

My reading of the code in read_char is that when we consume events
from unread-command-events, we don't always record the events we find
there.

Does the following naïve attempt at fixing this give good results?  If
not, can you tell why not, or show a test case where it misbehaves?

--- src/keyboard.c~0	2015-07-19 09:38:14.000000000 +0300
+++ src/keyboard.c	2015-08-06 17:46:30.596420600 +0300
@@ -2383,7 +2383,7 @@
   Lisp_Object tem, save;
   volatile Lisp_Object previous_echo_area_message;
   volatile Lisp_Object also_record;
-  volatile bool reread;
+  volatile bool reread, recorded;
   struct gcpro gcpro1, gcpro2;
   bool volatile polling_stopped_here = 0;
   struct kboard *orig_kboard = current_kboard;
@@ -2401,6 +2401,8 @@
 
  retry:
 
+  recorded = false;
+
   if (CONSP (Vunread_post_input_method_events))
     {
       c = XCAR (Vunread_post_input_method_events);
@@ -2990,6 +2992,7 @@
   /* Store these characters into recent_keys, the dribble file if any,
      and the keyboard macro being defined, if any.  */
   record_char (c);
+  recorded = true;
   if (! NILP (also_record))
     record_char (also_record);
 
@@ -3125,6 +3128,14 @@
       Vunread_post_input_method_events
 	= nconc2 (XCDR (tem), Vunread_post_input_method_events);
     }
+  /* When we consume events from the various unread-*-events lists, we
+     bypass the code that records input, so record these events now if
+     they were not recorded already.  */
+  if (!recorded)
+    {
+      record_char (c);
+      recorded = true;
+    }
 
  reread_first:
 

Re: Severe lossage from unread-command-events

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 05 Aug 2015 17:46:50 +0200
>> 
>> run the included test file using
>> 
>> emacs -Q -l timer-test.el
>> 
>> and then open the generated dribble file /tmp/mydrib.  On my computer,
>> it looks something like
>> 
>> 0000000000000000001111111111111111111222222222222222222223333333333333333444444444444444444555555555555555556666666666666666667777777777777777778888888888888888899999999999999999
>> 
>> which means that of 4000 events having an effect in the scratch buffer,
>> about 5% (a non-deterministic amount) are actually recorded in the
>> dribble file.  In particular, it looks like only the first of several
>> events placed into unread-command-events at one point of time will ever
>> see the dribble file.  While I am only moderately interested in actually
>> generating a useful dribble file, the same holds for macro recording.
>> And I have an actual application which is severely impacted here.
>> 
>> Note that _all_ of the events (usually) are actually processed as input
>> in the *scratch* buffer.  It is only the recording of them which falls
>> really, really flat on its face.
>
> My reading of the code in read_char is that when we consume events
> from unread-command-events, we don't always record the events we find
> there.

Well, according to how I read the variable description of
unread-command-events, some are bounced back there from input which has
already been recorded.  The description reads:

    Documentation:
    List of events to be read as the command input.
    These events are processed first, before actual keyboard input.
    Events read from this list are not normally added to ‘this-command-keys’,
    as they will already have been added once as they were read for the
    first time.
    An element of the form (t . EVENT) forces EVENT to be added to that list.

My test programs used (t . EVENT) after just using EVENT did not do the
trick either.  However, I don't think most of the other uses of
unread-command-events I have seen bother doing so.  It might or might
not be a red herring.

> Does the following naïve attempt at fixing this give good results?  If
> not, can you tell why not, or show a test case where it misbehaves?

I'll be giving it a try.  The code in keyboard.c is complex to a degree
where I do not trust myself to venture a guess regarding the nature of
the right fix.  Or whether the code is in need of reorganization before
one can hope to get it right anyway.

Thanks,

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Aug 2015 17:01:52 +0200
> 
> > My reading of the code in read_char is that when we consume events
> > from unread-command-events, we don't always record the events we find
> > there.
> 
> Well, according to how I read the variable description of
> unread-command-events, some are bounced back there from input which has
> already been recorded.  The description reads:
> 
>     Documentation:
>     List of events to be read as the command input.
>     These events are processed first, before actual keyboard input.
>     Events read from this list are not normally added to ‘this-command-keys’,
>     as they will already have been added once as they were read for the
>     first time.
>     An element of the form (t . EVENT) forces EVENT to be added to that list.

This talks about a different kind of "recording", the one that stores
keyboard input in this-command-keys.  My changes don't touch that (at
least I hope they don't ;-)

> The code in keyboard.c is complex to a degree where I do not trust
> myself to venture a guess regarding the nature of the right fix.

I agree.  I originally waited for one of the handful of people who
know their ways inside that function to speak up, but they never did.

To see what's going on, I instrumented the code with special
printouts, and clearly saw that we only record the events that are
taken from unread-command-events in one of two possible places in the
code, where we have fragments such as this one:

  if (CONSP (Vunread_command_events))
    {
      [...]
      c = XCAR (Vunread_command_events);
      Vunread_command_events = XCDR (Vunread_command_events);

One such fragment is at the beginning of read_char, around line 2430
of keyboard.c -- the events taken there are not recorded, because we
jump over the code that records them.  The second such fragment is
around line 2815 of keyboard.c -- the events we take there _are_
recorded by the call to record_char on line 2992.

Now, since your timer fires at very high frequency, many events are
pushed before we see them on line 2815.  We extract only the first
event there, and it is recorded.  The rest are handled by the code at
line 2430, and are not recorded, AFAICS.  My changes cause them to be
recorded, or at least your simple test seems to produce reasonable
results.

> Or whether the code is in need of reorganization before one can hope
> to get it right anyway.

It's next to impossible to reorganize code one doesn't fully
understand, and do a good job.

Re: Severe lossage from unread-command-events

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: David Kastrup <dak@gnu.org>
>>> Date: Wed, 05 Aug 2015 17:46:50 +0200
>>> 
>>> run the included test file using
>>> 
>>> emacs -Q -l timer-test.el
>>> 
>>> and then open the generated dribble file /tmp/mydrib.  On my computer,
>>> it looks something like
>>> 
>>> 0000000000000000001111111111111111111222222222222222222223333333333333333444444444444444444555555555555555556666666666666666667777777777777777778888888888888888899999999999999999
>>> 
>>> which means that of 4000 events having an effect in the scratch buffer,
>>> about 5% (a non-deterministic amount) are actually recorded in the
>>> dribble file.  In particular, it looks like only the first of several
>>> events placed into unread-command-events at one point of time will ever
>>> see the dribble file.  While I am only moderately interested in actually
>>> generating a useful dribble file, the same holds for macro recording.
>>> And I have an actual application which is severely impacted here.
>>> 
>>> Note that _all_ of the events (usually) are actually processed as input
>>> in the *scratch* buffer.  It is only the recording of them which falls
>>> really, really flat on its face.
>>
>> My reading of the code in read_char is that when we consume events
>> from unread-command-events, we don't always record the events we find
>> there.
>
> Well, according to how I read the variable description of
> unread-command-events, some are bounced back there from input which has
> already been recorded.  The description reads:
>
>     Documentation:
>     List of events to be read as the command input.
>     These events are processed first, before actual keyboard input.
>     Events read from this list are not normally added to ‘this-command-keys’,
>     as they will already have been added once as they were read for the
>     first time.
>     An element of the form (t . EVENT) forces EVENT to be added to that list.
>
> My test programs used (t . EVENT) after just using EVENT did not do the
> trick either.  However, I don't think most of the other uses of
> unread-command-events I have seen bother doing so.  It might or might
> not be a red herring.
>
>> Does the following naïve attempt at fixing this give good results?  If
>> not, can you tell why not, or show a test case where it misbehaves?
>
> I'll be giving it a try.  The code in keyboard.c is complex to a degree
> where I do not trust myself to venture a guess regarding the nature of
> the right fix.  Or whether the code is in need of reorganization before
> one can hope to get it right anyway.

Another data point would be Artur Malabarba's message about executing
keyboard macros which I answered in
<URL:http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00100.html>.

From glancing over your proposed fix, it's very much focused on dealing
with recording only.  Which has the advantage of not causing changes
elsewhere.  Artur's message, however, would suggest that there might be
a necessity for changes elsewhere.  I have no idea whether those changes
would be related or concern the same code.  I just wanted to bring this
up while I remember.  Artur's original report stated that he "noticed"
the problems "recently".  If that means that they started _occuring_
recently, they are probably an unrelated issue.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> To see what's going on, I instrumented the code with special
> printouts, and clearly saw that we only record the events that are
> taken from unread-command-events in one of two possible places in the
> code, where we have fragments such as this one:
>
>   if (CONSP (Vunread_command_events))
>     {
>       [...]
>       c = XCAR (Vunread_command_events);
>       Vunread_command_events = XCDR (Vunread_command_events);
>
> One such fragment is at the beginning of read_char, around line 2430
> of keyboard.c -- the events taken there are not recorded, because we
> jump over the code that records them.

That's bad because that sounds _intentional_.

>> Or whether the code is in need of reorganization before one can hope
>> to get it right anyway.
>
> It's next to impossible to reorganize code one doesn't fully
> understand, and do a good job.

In particular when it contains "somebody must have had a good reason for
this, so let's try to preserve some of those semantics" passages.  There
are several #if 0 passages in keyboard.c with various rationales in them
that might have applied at some point of time.

So my suspicion is that this change might result in problems that the
old code arrangement was intended to avoid.  But one will probably not
get new input on this without trying.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Aug 2015 17:33:25 +0200
> 
> Another data point would be Artur Malabarba's message about executing
> keyboard macros which I answered in
> <URL:http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00100.html>.

Then perhaps Artur should try the patch I posted, and see if it helps.

> >From glancing over your proposed fix, it's very much focused on dealing
> with recording only.

Not sure what exactly you mean by "recording" here.  What I tried to
do was not leave events that were not passed to record_char, except if
those events are substituted by other events (e.g., when they are
passed to an input method).

Re: Severe lossage from unread-command-events

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 06 Aug 2015 17:33:25 +0200
>> 
>> Another data point would be Artur Malabarba's message about executing
>> keyboard macros which I answered in
>> <URL:http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00100.html>.
>
> Then perhaps Artur should try the patch I posted, and see if it helps.
>
>> >From glancing over your proposed fix, it's very much focused on dealing
>> with recording only.
>
> Not sure what exactly you mean by "recording" here.  What I tried to
> do was not leave events that were not passed to record_char, except if
> those events are substituted by other events (e.g., when they are
> passed to an input method).

Well, Artur's problem was not concerned with recording but with replay.
So it would be sort of surprising if your patch made a difference for
it.  At least sort of surprising to me.  I think.

Anyway, got Emacs rebuilt and will now play with it.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Aug 2015 17:46:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To see what's going on, I instrumented the code with special
> > printouts, and clearly saw that we only record the events that are
> > taken from unread-command-events in one of two possible places in the
> > code, where we have fragments such as this one:
> >
> >   if (CONSP (Vunread_command_events))
> >     {
> >       [...]
> >       c = XCAR (Vunread_command_events);
> >       Vunread_command_events = XCDR (Vunread_command_events);
> >
> > One such fragment is at the beginning of read_char, around line 2430
> > of keyboard.c -- the events taken there are not recorded, because we
> > jump over the code that records them.
> 
> That's bad because that sounds _intentional_.

I thought about that, and tried to find any reason why such an
intention would be valid, but couldn't.  The comments therein mention
read_char_x_menu_prompt, but that function only records the first
event, and pushes all the rest onto unread-command-events.

If someone who reads this knows why these events were not recorded,
let them speak up now, or forever hold their peace.

> So my suspicion is that this change might result in problems that the
> old code arrangement was intended to avoid.  But one will probably not
> get new input on this without trying.

Indeed.  It could be that we will find something, but the current
situation is clearly unsatisfactory, and has to be fixed.  If the fix
uncovers other problems, we will have to solve them as well, but
without regressing back to what we have now.

Re: Severe lossage from unread-command-events

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Well, according to how I read the variable description of
> unread-command-events, some are bounced back there from input which has
> already been recorded.  The description reads:
>
>     Documentation:
>     List of events to be read as the command input.
>     These events are processed first, before actual keyboard input.
>     Events read from this list are not normally added to ‘this-command-keys’,
>     as they will already have been added once as they were read for the
>     first time.
>     An element of the form (t . EVENT) forces EVENT to be added to that list.
>
> My test programs used (t . EVENT) after just using EVENT did not do the
> trick either.

Uh oh.  This is bad news for macro recording of list events.

Defining kbd macro...
Auto-saving...done
<t> is undefined

and the "<t> is undefined" message comes with an abort of macro
recording.  Quite the nuisance.  So  I'll remove the t thing again and
will see how I fare then.

Now obviously if my events appear first in unread-command-events, they
cannot already have been added to this-command-keys, but at least list
events apparently must not be added in the (t . EVENT) form or
_something_ will attempt a lookup and fail.

Since the message appears only _once_, it would appear that the problem
stops occuring the moment macro recording by C-x ( has stopped.

What a can of worms.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Well, according to how I read the variable description of
>> unread-command-events, some are bounced back there from input which has
>> already been recorded.  The description reads:
>>
>>     Documentation:
>>     List of events to be read as the command input.
>>     These events are processed first, before actual keyboard input.
>>     Events read from this list are not normally added to ‘this-command-keys’,
>>     as they will already have been added once as they were read for the
>>     first time.
>>     An element of the form (t . EVENT) forces EVENT to be added to that list.
>>
>> My test programs used (t . EVENT) after just using EVENT did not do the
>> trick either.
>
> Uh oh.  This is bad news for macro recording of list events.
>
> Defining kbd macro...
> Auto-saving...done
> <t> is undefined
>
> and the "<t> is undefined" message comes with an abort of macro
> recording.  Quite the nuisance.  So  I'll remove the t thing again and
> will see how I fare then.
>
> Now obviously if my events appear first in unread-command-events, they
> cannot already have been added to this-command-keys, but at least list
> events apparently must not be added in the (t . EVENT) form or
> _something_ will attempt a lookup and fail.
>
> Since the message appears only _once_, it would appear that the problem
> stops occuring the moment macro recording by C-x ( has stopped.
>
> What a can of worms.

Looks like I can (and must) leave off the (cons t ...) for my use case.
I haven't seen any bad effects from doing so: events are looked up in
keymaps and recorded just fine so far.  I don't know what the
implications of the t thing are.  But other than that, things do look
good so far.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Stefan Monnier]

>> An element of the form (t . EVENT) forces EVENT to be added to that list.
> This talks about a different kind of "recording", the one that stores
> keyboard input in this-command-keys.  My changes don't touch that (at
> least I hope they don't ;-)

I'm not sure it's really unrelated.  The issue is that we don't want
events to be recorded twice if you "replay" them (i.e. do something
along the lines of (push (read-event) unread-command-events)).

>> The code in keyboard.c is complex to a degree where I do not trust
>> myself to venture a guess regarding the nature of the right fix.

This applies to everyone else as well :-(

> > recording.  Quite the nuisance.  So  I'll remove the t thing again and
> > will see how I fare then.

I think you need to use "the t thing" since your events aren't replays.


        Stefan

Re: Severe lossage from unread-command-events

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> An element of the form (t . EVENT) forces EVENT to be added to that list.
>> This talks about a different kind of "recording", the one that stores
>> keyboard input in this-command-keys.  My changes don't touch that (at
>> least I hope they don't ;-)
>
> I'm not sure it's really unrelated.  The issue is that we don't want
> events to be recorded twice if you "replay" them (i.e. do something
> along the lines of (push (read-event) unread-command-events)).
>
>>> The code in keyboard.c is complex to a degree where I do not trust
>>> myself to venture a guess regarding the nature of the right fix.
>
> This applies to everyone else as well :-(
>
>> > recording.  Quite the nuisance.  So  I'll remove the t thing again and
>> > will see how I fare then.
>
> I think you need to use "the t thing" since your events aren't replays.

According to the DOC string, I would be inclined to think so (it's very
hard to tell what the effect of doing or not doing so would be, and it
also seems to match the actual code rather loosely at best).  But Emacs
does not complain when I don't.  And it breaks macro recording when
I do.  And nobody else working with unread-command-events appears to be
doing it, either.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: David Kastrup <dak@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 07 Aug 2015 12:08:44 -0400
> 
> >> An element of the form (t . EVENT) forces EVENT to be added to that list.
> > This talks about a different kind of "recording", the one that stores
> > keyboard input in this-command-keys.  My changes don't touch that (at
> > least I hope they don't ;-)
> 
> I'm not sure it's really unrelated.

There are 2 separate calls to 2 different functions that do that, and
they are not called in the same places.

Re: Severe lossage from unread-command-events

[raman]

This may or may not be related -- but it's a problem I've been trying to
nail down for a while.

I most recently encountered it with high repro rates when using package
elfeed -- a feed-reader.

Elfeed keeps an index etc that can grow to 50mb plus -- it opens
those -- and updates them as well using idle  timers.

Effect/Issue: 

When those timers fire, and Emacs opens those archive files, it can pop
up the "file is x mb big, really open?" dialog. Now if this occurs while
you're at the keyboard, answering yes works -- and there is no
problem. However if this prompt occurs if you're away from your
keyboard,  or perhaps  working in  another window, then  it becomes
impossible to answer "yes/no" to that prompt from the  "file is too big"
dialog --- For elfeed the author checked in a fix that avoids the prompt
--- but the fact that an async generated prompt cannot be responded to
later is likely symptomatic of a deeper problem in input processing.


-- 

Re: Severe lossage from unread-command-events

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Looks like I can (and must) leave off the (cons t ...) for my use
> case.  I haven't seen any bad effects from doing so: events are looked
> up in keymaps and recorded just fine so far.  I don't know what the
> implications of the t thing are.  But other than that, things do look
> good so far.

Any chance for this patch going in anytime soon?  Anything I should be
doing here?

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 10 Aug 2015 18:56:42 +0200
> 
> David Kastrup <dak@gnu.org> writes:
> 
> > Looks like I can (and must) leave off the (cons t ...) for my use
> > case.  I haven't seen any bad effects from doing so: events are looked
> > up in keymaps and recorded just fine so far.  I don't know what the
> > implications of the t thing are.  But other than that, things do look
> > good so far.
> 
> Any chance for this patch going in anytime soon?  Anything I should be
> doing here?

I was waiting for you to tell whether it solves all the problems you
know about with pushing events onto unread-command-events.  If you are
satisfied by what you see after applying the patch, I will push.

Thanks.

Re: Severe lossage from unread-command-events

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 10 Aug 2015 18:56:42 +0200
>> 
>> David Kastrup <dak@gnu.org> writes:
>> 
>> > Looks like I can (and must) leave off the (cons t ...) for my use
>> > case.  I haven't seen any bad effects from doing so: events are looked
>> > up in keymaps and recorded just fine so far.  I don't know what the
>> > implications of the t thing are.  But other than that, things do look
>> > good so far.
>> 
>> Any chance for this patch going in anytime soon?  Anything I should be
>> doing here?
>
> I was waiting for you to tell whether it solves all the problems you
> know about with pushing events onto unread-command-events.  If you are
> satisfied by what you see after applying the patch, I will push.

So far the results looked good.  I suspect that it does nothing about
the "escaping e" problem of Artur.  And I suspect that the "(cons t"
feature will (still?) not work reliably.  However, neither of those
problems would appear to be caused by your patch, so there seems little
point in delaying that patch.

-- 
David Kastrup

Re: Severe lossage from unread-command-events

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 10 Aug 2015 19:47:06 +0200
> 
> > I was waiting for you to tell whether it solves all the problems you
> > know about with pushing events onto unread-command-events.  If you are
> > satisfied by what you see after applying the patch, I will push.
> 
> So far the results looked good.  I suspect that it does nothing about
> the "escaping e" problem of Artur.  And I suspect that the "(cons t"
> feature will (still?) not work reliably.  However, neither of those
> problems would appear to be caused by your patch, so there seems little
> point in delaying that patch.

Pushed.

Thanks for testing the patch.

Re: Severe lossage from unread-command-events

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 10 Aug 2015 19:47:06 +0200
>> 
>> > I was waiting for you to tell whether it solves all the problems you
>> > know about with pushing events onto unread-command-events.  If you are
>> > satisfied by what you see after applying the patch, I will push.
>> 
>> So far the results looked good.  I suspect that it does nothing about
>> the "escaping e" problem of Artur.  And I suspect that the "(cons t"
>> feature will (still?) not work reliably.  However, neither of those
>> problems would appear to be caused by your patch, so there seems little
>> point in delaying that patch.
>
> Pushed.
>
> Thanks for testing the patch.

Not at all.  It makes the difference between macro recording on Midi
events being mostly useless and being useful.  And if one is recording
multi-channel data (and an accordion regular sends on three channels:
right hand melody, left hand chords, and left hand basses), being able
to replay with different keymaps in order to separate one take into
various Voice contexts is pretty important.  In the long run, at least
the user interface for recording facilities will probably be look
different from C-x ( ... C-x ) but without even the basics working,
there is not much of an incentive for people to work on the trickier
stuff.

-- 
David Kastrup