emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Severe lossage from unread-command-events


From: Eli Zaretskii
Subject: Re: Severe lossage from unread-command-events
Date: Thu, 06 Aug 2015 19:21:06 +0300

> From: David Kastrup <address@hidden>
> Cc: address@hidden
> Date: Thu, 06 Aug 2015 17:46:28 +0200
> 
> Eli Zaretskii <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]